Re: [9fans] Non-stack-based calling conventions

[erik quanstrom <quanstro@quanstro.net>]

> 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