> COFF has had to cope with a certain monster dubbed portability; to adapt > to the peculiarities of the many flavors of UNIX (and at least one > Microsoft OS, with MS-COFF). So good it has been practically put out of > business by ELF or... do Plan 9 compilers output COFF object files?
see a.out(6). > COFF has had to cope with a certain monster dubbed portability; to adapt > to the peculiarities of the many flavors of UNIX (and at least one > Microsoft OS, with MS-COFF). So good it has been practically put out of > business by ELF or... do Plan 9 compilers output COFF object files? flat memory model: http://en.wikipedia.org/wiki/CDC_6600#Memory_organization > I am actually very grateful for having a flat 32/64 bit address space all > to myself. Even though the curse of managing virtual memory and driving > the associated hardware has been placed on every OS developer, occasional > programmers like me really enjoy the outcome. it's interesting to note that it is being loaded at a constant address makes the job of loading & generating the code much simplier. the location of allocated memory isn't as important --- those details can often be hidden in an malloc-style function. even on 386 hardware, segments can be used to cover all of memory. as long as your allocator knows where not to step (pci space, for example), this should be good enough. so if you're running without the operating system or your application is the operating system (embedded systems), virtual memory might just get in the way. tlb hardware doesn't do its translation for free. - erik
