From: | "BartC" <bc@freeuk.com> |
Newsgroups: | comp.compilers |
Date: | Wed, 29 Dec 2010 11:42:08 -0000 |
Organization: | A noiseless patient Spider |
References: | 10-12-040 10-12-052 |
Keywords: | storage, design |
Posted-Date: | 29 Dec 2010 09:34:40 EST |
"noitalmost" <noitalmost@cox.net> wrote in message
> Thanks all for your replies. They've been helpful.
>
> Tentatively, I'm calling my language Wipl (for Wirth Inspired Programming
> Language).
> Supposing Wipl, Oberon, and Ada to lie in the same "nanny language"
> category, Wipl sits much closer to Oberon than to Ada, though I
> think Oberon somewhat of a minimalist extreme.
> As for the use of Wipl, I would like to keep it in the "general
> purpose" category, mainly for applications, but also poentially for
> OS development. I was hoping one day to translate minix or (a
> subset of) linux to Wipl. This goal is what got me thinking about
> variant records.
> I suppose I have an initial prejudice against variant records. They
> seem to me to be a potential source of hard to find bugs (for the
> user programmer, I mean, not the compiler designer). Am I wrong
> about this? Is it possible for the compiler to always know which
> type is active in the variant, like say through a hidden
> compiler-generated variable in the record?
I thought the variant record also stored a tag field so that it is possible
to determine, at run time, exactly which fields are valid in the variant
part (although I can't remember exactly how this would be used in a
language; perhaps assign to the tag first, then write the appropriate
variant field which would then need to be runtime checked)).
This means the compiler wouldn't know what was going on in the record; it
would just have the headache of generating code to check the correct read
and write accesses are being done. (And I understand these variant fields
can be nested, an even bigger headache, if it's necessary to verify an
arbitrary path through a tree for any field access!)
In the case of a C union, no tag is stored; it's up to the programmer to
keep track of what shared field is currently active. But C is a low level
language and unions are one of the features it needs to support that aim.
And compiler support for unions can be minimal.
(In my own designs, I use neither variant fields nor unions. I use instead
field aliases:
record r (
int a, b
real x @ a
int c
)
so here x (64 bits) shares the same offset as a, and the same space as a and
b (32 bits each).
But this is also intended for nefarious purposes, and is an untidy feature
of a higher level language, with it's own problems (how many fields are in
this record?). However compiler support is straightforward: x is simply
assigned offset 0 instead of 8.)
So, my feeling would be to leave them out, provided you have enough other
features to make your OS work practical.
--
Bartc
Return to the
comp.compilers page.
Search the
comp.compilers archives again.