🚀 go-pugleaf

In article <1991Apr6.211320.18594@athena.mit.edu>, jfc@athena.mit.edu (John F Carr) writes:
> Why do you care what the address size is?  A programmer's concern should be:
> how many objects can I have, how big can each be, and how fast does the code
> run?

That's right.

> Let the system designers decide whether to have a flat address space
> or segments.

No, because that immediately limits me to "how big an object can be". And
the cost of RAM is continually dropping (see below)

> If you have code which requires 2^40 byte objects, put this in
> your requirements when you buy a system.

I might not, now. But some people are already using more than 2^32 bytes,
and single objects larger than that are already around the corner. You have
to consider your next system, and the system after that. Are you going to
be able to just buy the next larger version, change a few constants, and
deal with bigger problems with the same software?

> The cost of 2^40 bytes of memory
> can finance the OS and compiler changes needed to support such objects on a
> segmented MMU.

Let's pretend it's 1978 and we're looking to design a system.

So the cost of 2^20 bytes of memory should finance the OS and
compiler changes needed to support such objects on a segmented MMU,
so we'll build a segmented system.

And at late-'70s prices, when the 8086 was being designed, that was
probably true. By the time it came out, memory was cheap enough that
the original 64K was too small. But we're still stuck with the design
decision that software could cover for the segments in the off chance
anyone would ever need to go beyond 64K objects.
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"