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