home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.arch      Apparently more than just beeps & boops      131,241 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 130,192 of 131,241   
   Stephen Fuld to Anton Ertl   
   Re: branch splitting   
   07 Nov 25 10:45:39   
   
   From: sfuld@alumni.cmu.edu.invalid   
      
   On 11/7/2025 9:15 AM, Anton Ertl wrote:   
   > Stephen Fuld  writes:   
   >> On 11/7/2025 2:09 AM, Anton Ertl wrote:   
   >>> Stephen Fuld  writes:   
   >>>> On 11/6/2025 12:46 AM, Anton Ertl wrote:   
   >>>>> On such architectures switch would also be implemented by modifying   
   >>>>> the code,   
   >>>>   
   >>>> I don't think so.  Switch can, and I understand usually is,implemented   
   >>>> via an index into a jump table.  No self modifying code required.   
   >>>   
   >>> What does "index into a jump table" mean in one of those architectures   
   >>> that did not have indirect jumps and used self-modifying code instead?   
   >>   
   >> For example, the following Fortran code   
   >>   
   >> 	goto (10,20,30,40) I  @ will jump to label 10 if I =1, 20 if I = 2, etc   
   >>   
   >> would be compiled to something like (add any required "bounds checking"   
   >> for I)   
   >>   
   >> 	load 	R1,I   
   >> 	Jump 	$,R1	   
   >> 	Jump	10   
   >> 	Jump 	20   
   >> 	Jump 	30   
   >> 	Jump 	40   
   >   
   > Which architecture ist that?   
      
   It is generic enough that it could be lots of architectures, but the one   
   I know best is the Univac 1100.   
      
      
   >   
   >> No code modification nor indirection required .   
   >   
   > The "Jump $,R1" is an indirect jump.   
      
   Perhaps we just have a terminology disagreement.  I don't call that   
   indirect addressing. The 1100 architecture supports indirect addressing   
   in the hardware.  An indirect reference was represented in the assembler   
   by an asterisk preceding the label, which set a bit in the instruction   
   that told the hardware to go to the address specified in the instruction   
   and treat what it found there as the address of the operand for the   
   instruction.   
      
   So, for example:   
   	   
   	J	*tag   
      
   tag	finaladdress   
      
   would cause the hardware to fetch the address at tag and use that as the   
   operand, thus causing a jump to "final address".   
      
   This is what I call indirect addressing.   
      
   So to use this in an assigned goto, the assign statement would store the   
   desired address at tag such that when the jump was executed, it would   
   jump to the desired address.   
      
   I call the construct with several consecutive jump instructions an   
   indexed jump, not an indirect one.   
      
      
      
   > With that the assigned goto can   
   > be implemented as (for "GOTO X")   
   >   
   > load R1,X   
   > Jump 0,R1   
   >   
      
   Yes.   
      
      
   >>>>> and indirect calls and method dispatch would also be   
   >>>>> implemented by modifying the code.  If self-modifying code is "just   
   >>>>> bad", and any language features that are implemented on some long-gone   
   >>>>> architectures using self-modifying code are bad by association, then   
   >>>>> we have to get rid of all of these language features ASAP.   
   >>>>   
   >>>> And, by an large they have.   
   >>>   
   >>> We have gotten rid of indirect calls, e.g., in higher-order functions   
   >>> in functional programming languages?  We have gotten rid of dynamic   
   >>> method dispatch in object-oriented programs.   
   >>   
   >> No, and I defer to you, or others here, on how these features are   
   >> implemented, specifically whether code modification is required.  I was   
   >> referring to features such as assigned goto in Fortran, and Alter goto   
   >> in Cobol.   
   >   
   > On modern architectures higher-order functions are implemented with   
   > indirect branches or indirect calls (depending on whether it's a   
   > tail-call or not); likewise for method dispatch.   
   >   
   > I do not know how Lisp, FORTRAN, Algol 60 and other early languages   
   > with higher-order functions were implemented on architectures that do   
   > not have indirect branches; but if the assigned goto was implemented   
   > with self-modifying code, the call to a function in a variable was   
   > probably implemented like that, too.   
   >   
   >>> Thinking about the things that self-modifying code has been used for   
   >>> on some architecture, IIRC that also includes array indexing.  So have   
   >>> we gotten rid of array indexing in programming languages?   
   >>   
   >> Of course not.  But I suspect that we have "gotten rid of" any   
   >> architecture that *requires* code modification for array indexing.   
   >   
   > We have also gotten rid of any architecture that requires   
   > self-modifying code for implementing the assigned goto.   
      
   True.  But we still have my original argument, better expressed by   
   Niklas about code readability/followability.   
      
      
   --   
     - Stephen Fuld   
   (e-mail address disguised to prevent spam)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca