Trouble with arg & expand
Tyson Richard DOWD
trd at students.cs.mu.oz.au
Sun Feb 9 15:51:22 AEDT 1997
(Note - you probably need to know a fair bit about the implementation
of polymorphism for this to make much sense. If you do know about this
stuff, please correct me if I'm wrong).
Recently I've been working on getting arg and expand working
in `jump' and `fast' grade.
Jump and fast don't seem to have static code addresses. This means the
data for type_layouts (static tables) can't contain the addresses of
preds. (Because of this, they use one-cell type-infos).
So when you call arg on some data, the type_info that is returned
(packaged in a univ) can't contain the Index, Unify or Compare preds.
This causes fairly serious problems. The only way around it I can see
is to have initialization functions fill in the addresses of preds.
But if you are doing this, you might as well get them to use
shared-one-or-two-cell type-infos too.
So what I think we should do is use shared-one-or-two-cell type_infos
for all grades, and for grades without static code addresses, have each
module initialize the code addresses of base_type_infos contained in
that module. This will:
- slow down those grades because of extra initialization
(but they're not very fast anyway)
- slightly slow compilation (have to check for that feature, maybe
output init code)
- reduce binary size on those grades (base_type_infos are
generally a win)
- reduce complexity of polymorphism.m (can delete all code
for one-cell typeinfos).
- reduce complexity of code to manipulate typeinfos
(only one representation).
- allow arg, functor and expand to work unchanged.
Any comments or criticisms welcomed.
--
Tyson Dowd # Another great idea from the
# people who brought you
trd at .cs.mu.oz.au # Beer Milkshakes!
http://www.cs.mu.oz.au/~trd # Confidence --- Red Dwarf
More information about the developers
mailing list