🚀 go-pugleaf

In article <1991Apr06.030330.1533@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <VFIA832@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> >In article <1991Apr04.230953.15294@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
> >No, I didn't miss the point. If I have a 48 bit wide VM address and can't
> >operate on any object larger than a 32 bit wide pointer can address, then
> >it's a problem.

> Why is everybody harping on this 48 bits wide?

Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)

This subject started with the idea of using segments to expand the address
space of 32-bit computers. Many of us are still thinking along those terms.

> I actually never said
> anything about how wide the address space, except that I implied that it was
> at least 32 bits.  In fact, given the machine I proposed, it would still
> work quite well with only a 32-bit address space.

In fact, it would only work well with a 32-bit address space (or maybe 33 or
34 bits). Once you get much more address space available to a program than
you can stick into a single object you will run into problems: that's the
lesson of the 8086. The reverse situation is not a big deal: that's the
lesson of the 68000.

> And that's the difference
> between the flast and the segmented:  using the segmented version (which, as
> I pointed out two articles ago, can imitate, if slowly, a flat-address-space
> machine), I can hide the fact that I only have 32-address bits, virtual or
> otherwise.

My Amigas both have a flat address space, but one has 32 address bits and
the other 24. Apart from some trash software written by Microsoft, there
is no difference that the program has to deal with.

> Please read that agin, peter.  You assumed, incorrectly, that I had more
> than 32-bit for addressing.  You assumed that, if I cannot allocate a 5Gbyte
> object, things are broken.

So what's the advantage to segments?

> >Now, here's the important question: why is the 64K object size limitation
> >in the IBM-PC a problem? 

> Peter:  not all people who run into memory problems need more than 4Gbytes
> for a single object.

And not all people who run into memory problems need more than 64K for a single
object: that's one reason why ints in most IBM-PC C compilers are only 16
bits wide. For people who don't, they will never now that the machine can
access more than 64K, assuming, of course, it can.

Since ints are only 16 bits, there is no way to specify the size of an
object longer than 64K (that's why I was talking about 64 bit longs: size_t
can easily be an int), how are you going to know about it?

> >After all, you cannot write a correct program
> >that will fail on it. You cannot legally determine that the maximum
> >object size is >64K.

> Actually, for ANSI C, yes, you can.  You can use size_t for that purpose.
> And it's all perfectly legal.

size_t is 16 bits wide on most PC compilers.

> I admit freely that 32-bits is a limit.  But my question stands still:
> please show me a Correct (by K&R II, ANSI, or POSIX standards) C program
> that will fail [this system].

Can't. Can't show one that will fail on an IBM-PC either.

> You cannot even *write* a C program that tries to declare a single object
> with more than 4Gbytes (except by trying to pass something of type
> __longlong into malloc, which will then only look at half of it or fail, as
> the system wishes).

Can't write a C program that tries to declare a single object with more than
64K on an IBM-PC, since size_t is a 16 bit number.

> Now, once again:  please show me a Correct C program (defined above) that
> will fail on the system as I have defined it.

No, I'm not going to play with your straw man.

> Please note that, although a pointer is 64-bits, I have said nothing about
> how large the address space is.  I refuse to, as, since the way I've
> organized the machine, IT DOESN'T MATTER.

Has nothing to so with segments, either. The 68000, which I've already brought
up, is a counterexample.

> For people who want to have objects larger than 4Gbytes, if they pay me
> enough money, I will give them a special compiler and library that will
> allow it.  (As I said, that requires a little bit of work.)

So why not just use 64 bit registers in the first place, but only use the low
32 bits in the first versions... like the 68000 does. What do the segments
buy you?

> Actually, I want it because having every object in its own segment is an
> incredibly useful thing.

Just use the MMU and build your program with a sparse address space. You can
do anything you do with segments this way and you're not crippling the machine
at the starting gate.

Think of it as dynamically resizable segments, if you like. malloc can quite
easily make the top 'n' bits of any pointer unique, and the effective
result is exactly the same. Except you're not building the magic 2^32 into
the architecture.
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"