Re: Language design/VM design

Jeremy Boden <jeremy@jboden.demon.co.uk>
23 Mar 2000 03:31:32 -0500

          From comp.compilers

Related articles
Language design/VM design floris@vangog.net (Floris 'Tamama' van Gog) (2000-02-27)
Re: Language design/VM design joachim.durchholz@halstenbach.com.or.de (Joachim Durchholz) (2000-03-06)
Re: Language design/VM design jeremy@jboden.demon.co.uk (Jeremy Boden) (2000-03-06)
Re: Language design/VM design floris@vangog.net (Floris 'Tamama' van Gog) (2000-03-11)
Re: Language design/VM design jeremy@jboden.demon.co.uk (Jeremy Boden) (2000-03-23)
Re: Language design/VM design alanf@ns.net (Alan Fargusson) (2000-03-23)
Re: Language design/VM design joachim.durchholz@halstenbach.com.or.de (Joachim Durchholz) (2000-03-23)
Re: Language design/VM design floris@vangog.net (Floris 'Tamama' van Gog) (2000-03-28)
Re: Language design/VM design stephan@pcrm.win.tue.nl (2000-04-01)
| List of all articles for this month |

From: Jeremy Boden <jeremy@jboden.demon.co.uk>
Newsgroups: comp.compilers
Date: 23 Mar 2000 03:31:32 -0500
Organization: Compilers Central
References: 00-02-138 00-03-008 00-03-055 00-03-073
Keywords: design

Floris 'Tamama' van Gog <floris@vangog.net> writes
>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.
I think some of this has to be operating system/hardware driven. ...


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


The AS/400 is an unusual machine! It comes from IBM, contains a
database system which is integrated into the operating system; it also
supports alternative file systems. It supports all the mainstream
languages (plus RPG). It is a very scalable, multi-user machine used
for a moderate number of users, typically 10 - 500 of 'em. It's an
extremely secure machine and I've never heard of *anyone* writing a
successful virus for it (or its predecessor, the System 38) - that
covers about 20 years. It's also very easy to configure; a lot of the
communications (all varieties supported!) will auto-configure with no
user intervention.


Both machines were conceived as 64 bit machines (even 20 years ago). The
operating system etc is written in microcode which is then implemented
by the hardware available. I don't know if it's true but the story goes
that the hardware guys built the machine before the software
architecture had been finalised.


I can remember when they were running on actual hardware using 48 bit
CISC processors; the change to multi-processor 64 bit RISC processors
did not normally need any recompilation of user programs.


AFAIK The AS/400 & RS/6000 share quite a lot of the same hardware.


BTW Each machine is upwardly compatible at the object code level.
-
Jeremy Boden
[Actually, the AS/400 has an architecture that's never physically been
implemented. Each model does a binary translation of the AS/400 object
code to its native code before running a program. The architecture and
translations are spec'ed very tightly so the underlying machine is for
most purposes completely invisible to the programmer. Earlier models
used custom MSI processors, new ones use Power PC chips. -John]





Post a followup to this message

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