Re: Language design/VM design

"Alan Fargusson" <>
23 Mar 2000 03:32:29 -0500

          From comp.compilers

Related articles
Language design/VM design (Floris 'Tamama' van Gog) (2000-02-27)
Re: Language design/VM design (Joachim Durchholz) (2000-03-06)
Re: Language design/VM design (Jeremy Boden) (2000-03-06)
Re: Language design/VM design (Floris 'Tamama' van Gog) (2000-03-11)
Re: Language design/VM design (Jeremy Boden) (2000-03-23)
Re: Language design/VM design (Alan Fargusson) (2000-03-23)
Re: Language design/VM design (Joachim Durchholz) (2000-03-23)
Re: Language design/VM design (Floris 'Tamama' van Gog) (2000-03-28)
Re: Language design/VM design (2000-04-01)
| List of all articles for this month |

From: "Alan Fargusson" <>
Newsgroups: comp.compilers
Date: 23 Mar 2000 03:32:29 -0500
Organization: Compilers Central
References: 00-02-138 00-03-008 00-03-055 00-03-073
Keywords: architecture

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"
<> 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 <> 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.

Post a followup to this message

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