CompuServe Messages

Lattice C

#: 4377 S1/SoftwareForum unknown
    05-Jan-86 22:44:33
Sb: #4336-Lattice C
Fm: Russ Wetmore 76703,2010
To: Jack Crenshaw 72325,1327

This message turned up in search, but its forum couldn’t be identified from the original transcript, so it may not be linked into its thread.

You're correct regarding the semantics. I'm using the term "relocatable" to mean PC-relative, as in "this code can be relocated to anywhere in memory, even after loading, and operate without changes." PC-relative code is faster (slightly, but faster) than its absolute long equivalent, and requires 1/3 less code space. You can't MOVE PC-relative – this one limitation is generally handled by assigning an address register or two to the base(s) of global variables and indexing indirect off it/them. Again, address register indirect is faster, and less memory consumptive, than direct absolute addressing. Most of my experience writing 68000 code comes from the Mac. It _requires_ "non-absolute" (okay?) addressing because of its heap management. Code segments are treated no differently from other data in memory, and the system frequently shuffles segments around in the heap during compaction/garbage collection. Mac development environments (like assemblers) "help" you out by generating PC-relative code in response to "normal" language directives. Thus, you can write non-absolute programs without the extra syntax bogging you down. Since non-absolute code requires no load-time modification, is faster, and is less memory consumptive than absolutely located code, it seems almost ludicrous to not to support it (even mandate it) as the default addressing mode. [ Russ ] [ "Soapboxes'R'Us" ]