Re: Language design/VM design

"Joachim Durchholz" <joachim.durchholz@halstenbach.com.or.de>
23 Mar 2000 22:26:55 -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: "Joachim Durchholz" <joachim.durchholz@halstenbach.com.or.de>
Newsgroups: comp.compilers
Date: 23 Mar 2000 22:26:55 -0500
Organization: Compilers Central
References: 00-02-138 00-03-008 00-03-055 00-03-073
Keywords: architecture, design

Floris 'Tamama' van Gog <floris@vangog.net> schrieb in im Newsbeitrag:
> 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.
>
> [...]
>
> 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)


You could recheck pointer accesses against the allocation data. I.e. ask
the memory management library whether 'target' is a valid pointer to a
memory block.
If you wish to be really secure (depending on your time/security
tradeoff), you can let the memory manager issue time stamps and store
these in the 'pointer' structure. Or you drop the 'target' and ask the
memory manager what address belongs to each time stamp (this essentially
makes the time stamps into memory handles).


> Im interrested to see how the AS/400 (what is that anyway?)


It's the medium-size iron that IBM sells (and IBM is quite happy with
the sales figures I've been told).
A nice machine, a nice OS, a nice bang-to-buck ratio (especially when it
comes to reliability), and the worst programming/script language pair
that I have seen in my life (the programming language limits variable
names to 6 characters, the script language has only conditional jumps as
control structure, just to name the worst aspects).


> can guarentee type-safety and/or valid-references, as
> these seem to be my worse nightmares.
>
>
> 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.


IOW the machine can check whether your program has the privileges to
access some address space, but it cannot detect fencepost errors and
such.




Floris, could you tell a bit more about what you want to achieve? All
this checking stuff is going to be a performance pig, especially if a
lot of pointer dereferencing is going on. It might be useful to take a
different approach, like giving every C library its own address space
(including its personal 'malloc') so that a rampant C program isn't
going to kill anybody except itself.


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


I reckon that the AS/400 doesn't check data types, just access
permissions on a per-address space basis. As AS/400 address spaces can
be quite small (e.g. printer configurations are kept in separate spaces,
as are fonts IIRC), this is still a useful safety measure even if it
doesn't scale well beyond the handful of system address space types that
are available.


Regards,
Joachim


Post a followup to this message

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