Re: Pascal Calling Convention

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccy63xspih.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
>>...The problem with segments
>> is segments that are too small, not the basic idea.
>
> One problem with segments is that you need twice as many address
> bits to address the same amount of memory.  If you give me a 64-bit
> address that has a 32-bit segment number and a 32-bit offset,
> they're too small, and not enough of them (for some purposes).
> I'd rather have a 64-bit flat address space.  So maybe you give
> me a 128-bit address.  Now there are plenty of segments and they're
> plenty big, but you've hugely increased the size of all my pointer-heavy
> data structures, causing all my programs to run slower.  In that case,
> I still want a 64-bit flat address space.

You're thinking completely wrong. You almost never would want an address of 
any arbitrary memory, so the segment is almost always implicit. All of the 
data goes into a data segment; you never have data addresses that point 
somewhere else. All of the code goes into a code segment, you never have 
code addresses that point somewhere else.

In the rare case that you need extra segments (such as implementing 
'Address), yes the addresses are a bit longer. But those cases are so rare 
that you'll hardly ever see them in practice. (Also, there is no reason for 
segment numbers to be more than 16 bits, there should never be more than a 
handful per program.) The size of System.Address in Janus/Ada was 48-bits 
(16 bit segment, 32 bit offset); we finally changed that to drop the segment 
for the Windows version just a couple of years ago because it was (very) 
occassionally causing trouble. The code generator still understands the 
48-bit type.

And the maximum segment size should always be the same as the maximum 
address space (32-bits on a 32-bit machine, 64-bits on a 64-bit machine). 
Although I think you could make an argument for a 48-bit segment size and 
16-bit segment value size on a 64-bit machine; 48-bits comes close to the 
maximum amount of memory that will be constructable in a digital machine.

> And if you don't like buffer overruns, use any langauge that
> prevents them (like Ada and many others).

One use of pragma Suppress or an interface to the OS or one bug and that 
"protection" is gone.

99% of the time, executing data is a bug. Why allow it by default?

> Note that x86 segmentation
> won't do array-bounds checking correctly, so the compiler has to
> implement it in software anyway.  (Think about a packed array
> of Boolean.)

That's not relevant to my point, which is simply that not allowing the 
execution of data in the default case would prevent almost all code 
injection attacks (usually accomplished via buffer overflows, but there are 
lots of other ways). There is no protection against clobbering data, and I 
don't think there can be any (besides the software techniques) unless the 
hardware supports very fine-grained memory management -- and that is likely 
to be far too much of a drag on performance.

...
>>... As soon as you are
>> talking about hardware or implementations, you are talking in a
>> target-specific way, ...
>
> Not at all.  The statement "All Ada implementations must use a stack
> to implement procedure calls, because the semantics are FIFO."
> is talking about implementations, but it's not target-specific.

I think it is also close to junk. The semantics are FIFO is fine, but 
anything about the underlying data structure is bogus. Unless you are 
equating FIFO with stack in all cases, which I don't agree with. A stack is 
FIFO, but I don't think that implies that all data structures that are FIFO 
are stacks.

Anyway, this is a pointless discussion. Let's go back to discussing whether 
membership is a set operation. ;-)

                      Randy.