Related articles |
---|
[8 earlier articles] |
Re: JVM as UNCOL, was ANDF/TDF vbdis@aol.com (2001-10-13) |
Re: JVM as UNCOL, was ANDF/TDF fjh@cs.mu.OZ.AU (2001-10-16) |
Re: JVM as UNCOL, was ANDF/TDF fjh@cs.mu.OZ.AU (2001-10-16) |
Re: JVM as UNCOL, was ANDF/TDF joachim_d@gmx.de (Joachim Durchholz) (2001-10-20) |
Re: JVM as UNCOL, was ANDF/TDF vbdis@aol.com (2001-10-20) |
Re: JVM as UNCOL, was ANDF/TDF lex@cc.gatech.edu (Lex Spoon) (2001-10-20) |
Re: JVM as UNCOL, was ANDF/TDF chase@world.std.com (David Chase) (2001-10-23) |
Re: JVM as UNCOL, was ANDF/TDF marcov@toad.stack.nl (Marco van de Voort) (2001-10-28) |
Re: JVM as UNCOL, was ANDF/TDF alexc@world.std.com (2001-11-04) |
From: | David Chase <chase@world.std.com> |
Newsgroups: | comp.compilers |
Date: | 23 Oct 2001 20:22:27 -0400 |
Organization: | Compilers Central |
References: | 01-10-063 01-10-095 |
Keywords: | OOP, Java |
Posted-Date: | 23 Oct 2001 20:22:27 EDT |
Lex Spoon wrote:
> Now, the question everyone is avoiding, is whether *real* C programs
> will work under this regime, not just strict ANSI C programs. :)
Gzip would work. When I worked at Centerline, of all the programs
that I crammed through the tool I was working on, only gzip was
completely free of complaints.
> I've thought about this problem in another context, and my guess is that
> you will want to use an array of words implementation even though it's
> cleaner to represent pointers as array-plus-offset.
You would definitely need to represent memory as a single contiguous
array, and not have separate arrays for different "pointers". People
DO take the difference of pointers. Emacs is one notable offender; in
particular, it contains (contained?) a macro that:
allocates p
subtracts q to form pmq
copies from q to q + (pmq)
frees q
reforms p from q + pmq.
Don't ask me why, I am just the messenger. This little atrocity is
memorable because, if you are designed a tool to report errors
detected at runtime, what on earth are you supposed to say? (You
cannot say nothing -- the difference of pointers is a minor error,
since it "works" on all platforms of economic interest, plus most of
the uninteresting ones, but the reference to the freed pointer is
generally regarded as a Bad Thing.)
Another thing to watch out for is assumptions (and I have made these
myself) about page size and alignment. Since I "know" that pages
(protection domains) are aligned on at least 512 bytes (or some larger
power of two) and also have a size that is some integer multiple of
512 (or larger), then it is always "safe" to load the entire (aligned)
word containing any single byte -- even if the array containing the
byte ends before the end of the word. (The tool I was working on
caught this in my own bit-blitting code.)
> And don't forget, by the way, that the C stack needs to be in that
> array, too, so that pointers to stack-allocated variables will work
> correctly.
Yup. I (from when I worked at Sun) saw a bug reported against a new
version of the C compiler -- someone's pointer arithmetic between two
stack variables no longer worked properly. They worked for a Large
Customer, so the response was (I gather, from how it was relayed to
me) as polite as possible, given that even though the customer is
always right, sometimes, they really, truly, are not.
David Chase
chase@naturalbridge.com
drchase@alumni.rice.edu
chase@world.std.com
Return to the
comp.compilers page.
Search the
comp.compilers archives again.