> Currently, libid and idc only support 1 tag: fixnum or allocated object. All > fixnums in idc and above require masking and shifting before operations. A > fixnum operation heavy program, for example, would benefit from using 00 tags, > as in SBCL, unless tags can be optimized away by type inference or > declaration. > > The idea to parameterize the tagging, to avoid hard-wired low-level decisions > about tag schemes by opening it up to higher levels of abstraction, Jolt for > example. Hard-coded decisions about tagging and word size created problems > when porting it to 64 bits.
Yes, it will useful to have this before porting to new architectures. Has anybody started on an (x86) 64-bit port of the code generator? I would like to collaborate if someone is working on this. > > In general I agree with Adrian Kuhn (who commented on your blog post) > > that the benefits of one tagging scheme versus another are doubtful. In > > the context of idc or my language implementation, there are many avenues > > for optimization open for exploration which will likely yield more > > benefit. > > > > John > > > > Adrian correctly pointed out that tagging is a time/space trade-off. I did > demonstrate that different processors did perform differently by varying > tagging schemes. Yes, the current tagging scheme (with 0 as nil) seemed to perform best in your benchmark. But will it make a difference for more typical usage (such as idc compiling itself)? > There is an interest in porting FoNC to smaller and larger > architectures. If tagging schemes have limited benefit then why decide on any > tagging scheme? There are valid reasons modern systems do not use high-bit > tags; I propose there are valid reasons to not hard-code a particular tagging > scheme into a flexible system like FoNC. Sure John _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
