Okay. Although I'd like to ask if you can implement the Anarki 'defcall and 'call* too?
Basically this means that instead of updating the pc C-var at END_JUMP(), our jump: C-label does the updating. If it's an ordinary function, extract pc from CLOSURE_REF(LOCAL(0),0). If it's not, lookup its type in the call* table, and rearrange the stack:
(obj k . ind)
=>
((call* (type obj)) k obj . ind)
This also means that closures need type tags now too.
Ok, I'll work on this too. I need to type closures now anyway, as I am implementing full support for things like pr and type.
Btw, about type tags and the pointer-as-fixnum hack : I read a paper about the implementation of Lua (for tips about tables implementation). In Lua, everything, including numbers, is implemented as a structure containing first the type, then the data for the actual object (somebody already mentioned this in the forum). The reason is that the ANSI C standard does not allow the pointer-as-fixnum trick : you cannot know for sure that addresses will have a 0 low bit. In practice, it works on the most common architectures, but it's not fully portable (which is a problem given Lua's target). Hmm, you were right, maybe later we could add another version of codegen that would be slower and more memory-consuming but completely portable.
True, which is why I was always a bit leery of the trick. Besides, if you're going to implement bignums anyway, you might as well start off "fixnums" as very small bignums ^^. LOL. Of course there's the obvious problem that most applications won't use bignums, and in applications that do, most numbers still aren't bignums.
But then, if you add two fixnums together and the result won't fit in a fixnum...
As an aside, in the current mzscheme implementation, it seems fixnums are type 'int and everything else is type 'num
Finally: if you need to access call* , it may be possible to determine its position in GLOBAL() and add a C-global CALL_STAR: