Re: Language design/VM design

I have Soltis book "Inside the AS/400". In it he goes into a lot of detail
on how pointers work in the AS/400. I don't want to re-read the book right
now so I will describe how pointers work as I remember it.


Actually the 128 bit addresses are only used in the intermediate code that
OS/400 uses. The actual machine code for the POWER chips that are used have
64 bit pointers. The registers are actually 65 bits however. When a
register is modified the extra bit is set. When memory is addressed using a
register with the bit set the hardware traps to the OS, which checks the
pointer. If the pointer is valid the OS resets the extra bit and resumes
the program.


A pointer can be set to any value you want, but if you use a pointer that is
not valid the OS will abort your program.


----------
In article 00-03-073, "Floris 'Tamama' van Gog"
<floris@vangog.net> wrote:




> Yes large pointers also seem to be my solution, although this would add
> some overhead. I'll have to see how much overhead this is in readity.
>
> I was thinking about 12 byte pointers:
>
> struct pointer{
> int offset;
> int byte_size;
> void *target
> };
>
> This would allow all pointer arithmic, would make runtime bound-checking
> possible, and guarentee that pointers stored in VM address space can not
> be changed.
>
> What this would also do is change the need for different accessing
> methods (stack, data segment, extern)
>
> example:
>
> char foo[80];
> char *bar=foo+5;
>
> bar would then contain { 5,75,pointer_to_foo+5 }
>
> Then pointers can be safely in/decremented by using the offset/bytesize
> combo. The pointer::offset is used to safely decrement pointers (if only
> incrementing was allowed, then this field would not be required)
>
> Or something like that :-)
>
> However this still has the possibility of dangling references, which
> could then *%#%* things up. Using another 4 bytes (it alligns nicely
> to 16 bytes then) for some sort of refcounting or I dunno, something
> to make it 'secure' (not crashing the host)
>
> I already removed the typecast from 'my' language, as they are nasty
> things anyway.
>
> Im interrested to see how the AS/400 (what is that anyway?) can
> guarentee type-safety and/or valid-references, as these seem to be my
> worse nightmares.
>
> Thanks,
>
> Floris
>
> Joachim Durchholz <joachim.durchholz@halstenbach.com.or.de> writes
>> ...
>> >I assume you mean a type cast with "change" in the above. In that
>> >case, if you want pointer arithmetic and external/internal pointers,
>> >disallow casts between internal and external pointers.
>> >
>> >The AS/400 has exactly the same problem: they have C on a machine with
>> >external pointers to operating system objects. They have a tougher
>> >problem in that they have full ANSI C, so they cannot disallow type
>> >casts.
>
> Jeremy Boden wrote:
>> All AS/400 pointers are actually 8 bytes (128 bits); basically 64 bits
>> points to a machine space or object and the other 64 bits as the space
>> offset. This is true regardless of whether a pointer is to an "internal"
>> or "external" address. I believe there *could* also be some limited
>> checking to ensure that the 8 byte field is a pointer.
>>
>> The AS/400 will check that a pointer is valid and that it references an
>> object to which you have access. Actually I have always wondered how
>> void casts are done, since the machine can't check what kind of object
>> is being accessed via the void pointer.
>

Return to the comp.compilers page.
Search the comp.compilers archives again.