[uticus]

> Less immediately visible to someone working at the assembly language level instead of the machine code one is that relative addressing is much more common on the 6809, meaning that it’s significantly more viable to write position-independent code on it than any of the other chips we’ve looked at here. Only the 8086 comes close, and it achieves it by using its segment registers as a de facto relocation base.

I would love to learn more about this. Does more "position-independent code" mean the linker has much less to do [0], or is there an actual difference in the code base for similar tasks?

[0] https://sourceware.org/binutils/docs/ld/Overview.html

[watersb]

"Linker"?

In theory, the motivation for position independent code was to support the development and use of software libraries that could be "plugged in" to an application.

In practice, RAM was often limited to 16 KB; software reuse that I'm familiar with on a 6809 platform was at the source-code level and optimized by the programmer.

I remember editing and assembling, but not compiling or linking.

That said, I believe Motorola wrote some floating-point libraries.

I was a kid on a Tandy Color Computer, and the $49.95 EDTASM cartridge was a huge investment for our family. So my point of view could be way off... but the simplicity of the Color Computer with the design of the 6809 made programming delightful. (20 years later, my enjoyment in programming the Palm Pilot felt like that... although by then I could use C as a fancy macro assembler.)

Larger and later systems could use OS-9, which reasonably resembled UNIX and maybe supported a C compiler.

[analog31]

I believe that linking became important when programs got too big to compile within the memory limits of the computer. Then you had to compile portions of the code into separate object files, and then "link" those object files by reconciling the identifiers with their addresses. Without having to haul everything back into the compiler at once. It also meant that portions of a program didn't have to be recompiled if they weren't ever changed.

This wasn't the only way to skin the cat. Multi-pass compilers were another way.

Relocatable code could make more efficient use of memory, for instance not having to worry that your object code would end up crossing a page boundary after linkage.

[whartung]

Technically it wasn’t the linker that’s simplified, it’s the loader.

Modern systems don’t worry about PIC code, they have virtual memory so everyone sees memory the same. The virtual memory system manages the relocation automatically.

OS/9 relies pretty much entirely on PIC code, that made the loader and multi-tasking easy.

Original MacOS also relied on PIC. For similar reasons, and it’s partly why code segments were limited to 32k.

Then you have things like the original 8086. As long as you stick with the “tiny”/“small” memory models, everything was relative to the segment registers, so code and data could be moved easily.

In contrast you had systems like the Apple IIGS. The 65816 does not support PIC well, so code segments carry a relocation table that allows the segment loader to relocate code during transfer from disk. The creation of segment and relocation table is the job of the linker.

[peterfirefly]

> Modern systems don’t worry about PIC code

https://en.wikipedia.org/wiki/Address_space_layout_randomiza...

[gblargg]

It still needs to be relocatable because even VM can't allow two modules to occupy the same address range and run at the same time.

[spc476]

In general, yes, the linker (if there is one) would have less to do.

Position independent code (PIC) on the 6809 is pretty easy [1], but it does increase the code side a bit, but the resulting code can be placed anywhere in memory with no changes and still work. As mentioned, Motorola intended to sell a ROM with IEEE-754 floating point routines for the 6809 (as the MC6839) that was PIC. As far as I could tell, they never did sell the ROM, but they did provide it (with source) for anyone to use.

[1] Relative branches instead of absolute jumps, using the index registers to address memory, as well as addressing relative to the program counter. You can still do jump tables, but instead of a list of addresses, they're just a list of relative jump instructions. That type of thing.

[syncsynchalt]

On older hardware such as this it could e.g. let you write a multitasking environment that supported shared libraries without use of an MMU (though you'd hit memory constraints pretty quickly on a Z80-era cpu!).

I'm not familiar with the instruction sets of the 6809 but I could also see more compact opcodes, e.g. a JMP with a relative offset can be encoded smaller than JMP with an absolute address.

In modern terms PIC is used for ASLR and is therefore a security requirement. Some arches (I'm most familiar with arm64) are entirely designed around PIC and you need extra hoops to do anything in absolute terms.

[le-mark]

In practice it just meant the “zero page” could be anywhere, not the 256 bytes starting at 0x00 (like the 6502 zero page). The opcodes that operate on zero page are shorter and thus faster.