[m-dev.] 4 tag bits

[Zoltan Somogyi]

On Wed, 6 Jul 2016 10:58:45 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> In principle, everything affected by the number of tag bits should to
> be controlled by the macro MR_TAGITS and its friends.

In the runtime. In the compiler, there is the num_tag_bits option,
but I strongly suspect that there is also code in the rest of the compiler
that will throw an exception if its value is neither 2 nor 3. You should
grep for the option name, and have a look at make_tags.m (which makes
decisions about tag values).

There is also the issue of the RTTI that describes the representation
of data types for the debugger and accurate gc. This has components
in the compiler, runtime and (maybe) trace directories. This includes
some hand-written RTTI structures (most hidden behind macros).
Most of these won't depend on the number of tag bits, but some may
(or may not; I don't know offhand).

If you try things out and they don't "just work", I am pretty sure
I am in a better position to find any problems than anyone else,
since I worked on these parts of the system more than anyone else,
So if there *are* problems, just pass the problem to me.

> Sure, although the use of the extra tag bit should be optional to
> begin with.

Great. Another grade component :-(

But nevertheless: agreed. At least, we need to compare the
speed of 3 vs 4 tag bits before we pick one to keep, after testing.

You will want to use the grade macro that distinguishes the 4-bit tag
grade from the other grades to make your runtime directory's .c files
compile to .o files correctly both when your stage 1 is in a current
grade and when the stage 2 is a 4-bit-tag grade.

Zoltan.