Re: [Squeak-VMdev] DING! End of Round One

[Ian P. <ian...@in...>]

Hi Dan,

Great r=E9sum=E9 (even if I do feel obliged to take issue with a couple =
of=20
items in it ;-).

> Compact classes
> Nobody seems to care much here.  I was impressed that Andreas picked=20=

> up on the slight "tagging" advantage that CCs offer.  This actually=20
> saves an instruction or two testing for contexts, as I recall.

But, it's also a royal pain when you decide you want to evict Context=20
from the set of compact classes.

If minimising space by keeping CCs is our prime goal, then I'm entirely=20=

neutral on the issue.

If minimising (Context) membership test time by keeping CCs around is=20
our prime goal, then I'm entirely against it.  It would make certain=20
classes "privileged", in that you can *never* make them non-compact=20
without breaking your VM.  Otherwise it means the VM can never use CC=20
fields exclusively to check for membership (it would still have to load=20=

the class generically and test pointer eqv).  This kind of defeats the=20=

argument for keeping CCs around -- entirely.

I actually think it would make for the fastest possible execution if=20
compact classes just went away leaving all class pointers explicit in=20
the method header.  No bit fields to extract.  No privileged CC indices=20=

to "secretly know about".  No branch-over-check-for-CC-index that might=20=

be zero requiring a punt to class header load and compare.  Instead:=20
just one simple, consitent, linear thing.

> SmallIntegers
> We had some interesting discussion about changing the format of=20
> SmallIntegers.  I'm going to invoke executive privilege however, to=20
> say that we will not change the current representation on this go=20
> round.  I'm sure it would be an interesting exercise, but I don't see=20=

> a really big payoff, and I can imagine it ending up being a lot of=20
> work.
>
> If anyone wants to do this on their own and give me the code, or if=20
> they want to argue one last time for the benefits, I'm still willing=20=

> to reconsider.  I really mean this -- i just don't want to get bogged=20=

> down in gratuitous changes.

The only tag change I would push for is putting SI tag in the topmost=20
bit.  But Tim (or rather risc-os) killed that one stone dead.

> The 64-bit format
> My inclination is to tie this as closely to the 32-bit format as=20
> possible for now, just to simplify the project.  To me that means just=20=

> extending every oop, and header word with zeroes, and sign-extending=20=

> every "small" integer.  For now, we'll also stick with the same 31-bit=20=

> value range in both systems.
>
>
> Form bits modulus
> I want to change the modulus of Form bitmaps to 64 bits in both 32-=20
> and 64-bit images. As per discussion this does not change the format,=20=

> only the raster width.

Something is itching me about making Forms 64-bits deep while retaining=20=

31-bit integers.  I can't really put my finger on it, but the phrase=20
"LargeInteger explosion" is floating around my head for some reason...

> CompiledMethods
> A major question to decide is whether to split up bytecodes and=20
> literals

*Yes*.

> (and source pointer)

In the CM (or in the literals if you can fathom a reason to prefer=20
that).

> and throw in a "serendipity" field for fun this summer.

Let's just make the VM completely agnostic w.r.t. the size of CMs. =20
Stick the variable pointers where pointers belong, stick the bytecodes=20=

where variable bytes belong, and stick fixed fields (including method=20
header) where fixed fields belong -- in something about which the VM=20
never makes assumptions beyond the first N fields and which never cares=20=

if someone subclasses it in cruel and unusual ways.

> [By the way, I'm assuming this adds another very high bandwidth=20
> register to access literals independent of bytecodes, right?  And Ian=20=

> please comment on the relative importance of 3 objects vs two]

For interpretation you maybe want to care (a teeny bit) about=20
minimising the number of "hot" registers, but for all architectures bar=20=

one (the one that lets you get at 8 out of the 64? 128? registers ;)=20
this is utterly irrelevant: we still have plenty of "fixed" registers=20
to spare.

For a translating runtime I'd want the simplest and most generic model=20=

possible.  Each object has precisly one function (separate out the CM,=20=

literals, bytecodes) and -- whatever else we end up deciding to do or=20
not to do -- get those #^$*@! block bodies out of their defining CM and=20=

into their own, independent CM once and for all! ;)

> Closures
> I'm just assuming we would load some form of Anthony's work, which=20
> probably also means using his compiler.

Is this a modified St-80 Compiler, or one based on SmaCC?

If the latter than I'd vote for this (compiler change) faster than I'd=20=

vote for Ralph Nader (which is pretty darn fast ;).

> Ian, are you happy with the structures he chose, or should we make=20
> some changes before loading them up?  We probably want to start with=20=

> something that doesn't change the existing context structures much.

I'd like to talk with Anthony about this (great) detail, in a much=20
higher-bandwidth setting than a mailing list, and come to a unanimous=20
concensus on the optimal bang-for-the-buck to be had in a "short-term=20
project" (paying equal attention to the efficiency of interpretive and=20=

translational approaches).  I think we can come up with something novel=20=

that will be sufficiently close to what we have to make for very little=20=

implementation impact, yet yield significant performance benefits.

In any case I think it's important not to lose much of Anthony's work,=20=

but at the same time I think we have a great opportunity to "undo"=20
several mistakes that were made in the past (by all concerned -- I'm=20
not pointing fingers at Anthony or anyone else in particular, nor=20
disclaiming responsibility for my own fair share of them!).

> Order of evaluation
> I know we've chatted about this in the past, and believe me I *want*=20=

> to do this.  Unfortunately, I think for Squeak it would be a mistake.

I think _not_ to do it would invalidate a lot of very useful stuff that=20=

could be done elsewhere, in primitive calling conventions, translating=20=

runtimes, etc...

> There is a fair amount of useful software (mainly compilers) in the=20
> community that has the left-to-right convention built in.

Then maybe _they_ are broken?  We should fix them (not make concessions=20=

to them).

George Bernard Shaw:  The reasonable man adapts himself to the world;=20
the unreasonable one persists in  trying to adapt the world to himself.=20=

  Therefore all progress depends on the unreasonable man.

(I like that one almost as much as I do the one about "cheating and not=20=

getting caught".  ;)

> Then there is the occasional bad usage of the form (strm next * 256 +=20=

> strm next), but they deserve what they get.

Hear hear!

> I'm mainly concerned about bucking a convention that has paid off in=20=

> synergy over the years.

Depending on any undefined (by some standard someplace) implementation=20=

behaviour is a bug (even if the program runs without exhibiting any=20
erroneous behaviour).  You would not find any C programmer (beyond=20
elementary school, or Redmond maybe ;-) writing the C equivalent of the=20=

above Stream example.  Smalltalk programmers should be every bit as=20
careful: (AFAIK) the eval order is not specified by the standard.

(Somebody please, *please* correct me if I'm wrong about this.  I can't=20=

find my copy of the standard to check.  Is it online anywhere yet?)

> Separate Allocation of some Bits Objects

Separate allocation of "locked-down" (or "wired" or "non-moving" or=20
whatever) objects of any format.

> Proxy support (divergent "self' and "receiver")
> Is 'receiverMap' (ie a spare slot in Contexts) enough for now?

I think so.

Hope that was useful (and not too contentious and/or factually=20
inaccurate)!

Cheers,
Ian