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,494 of 131,241   
   David Brown to Dan Cross   
   Re: instruction ordering, was Memory ord   
   12 Dec 25 15:28:30   
   
   From: david.brown@hesbynett.no   
      
   On 12/12/2025 14:05, Dan Cross wrote:   
   > In article <10hfrsl$145v$1@gal.iecc.com>, John Levine     
   wrote:   
   >> According to Thomas Koenig  :   
   >>> MitchAlsup  schrieb:   
   >>>   
   >>>> Heck, there are assemblers that rearrange code like this too much--   
   >>>> until they can be taught not to.   
   >>>   
   >>> Any example?  This would definitely go against what I would consider   
   >>> to be reasonable for an assembler.  gdb certainly does not do so.   
   >>   
   >> On machines with delayed branches I've seen assemblers that move   
   >> instructions into the delay slot.  Can't think of any others off hand.   
   >   
   > I've seen things like this, as well, particularly on machines   
   > with multiple delay slots, where this detail was hidden from the   
   > programmer.  Or at least I have a vague memory of this; perhaps   
   > I'm hallucinating.   
   >   
      
   I've seen a few assemblers that do fancy things with jumps and branches   
   - giving you generic conditional branch pseudo-instructions that get   
   turned into different types of real instructions depending on the   
   distance needed for the jumps and the ranges supported by the   
   instructions.  And there are plenty that have pseudo-instructions for   
   loading immediates into registers that generate whatever sequence of   
   load immediate, shift-and-or, etc., are needed.   
      
      
   > More dangerous are linkers that do LTO and decide to elide code   
   > that, no, really, I actually need for reasons that are not   
   > apparent to the toolchain.   
   >   
      
   IME you have control over the details - either using directives in the   
   assembly, or in the linker control files.  Of course that might mean   
   modifying code that you hoped to use untouched, and it's not hard to   
   forget to add a "keep" or "retain" directive.   
      
   I've found link-time dead code elimination quite useful when I have one   
   code base but different binary builds - sometimes all you need is a   
   different linker file.   
      
   --- 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