Re: Language design/VM design

"Floris 'Tamama' van Gog" <floris@vangog.net>
11 Mar 2000 13:33:26 -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: "Floris 'Tamama' van Gog" <floris@vangog.net>
Newsgroups: comp.compilers
Date: 11 Mar 2000 13:33:26 -0500
Organization: XS4ALL Internet BV
References: 00-02-138 00-03-008 00-03-055
Keywords: design

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.



Post a followup to this message

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