John Leuner wrote: > 32-bit machines also don't need the lower 3 bits if you align all > objects by 8 bytes. >
Obviously. In fact many common allocators will align to 8 bytes. > In my Church-State implementation I adopted some of the conventions used > by the SBCL lisp implementation, see the tags here > > http://subvert-the-dominant-paradigm.net/repos/hgwebdir.cgi/bootstrap/file/3ec558141ebc/church/runtime/church_types.state > > and the sbcl page describing the tags: > > http://sbcl-internals.cliki.net/tag%20bit > > The main rationale is that fixnums can be added without shifting (and > can be used to index word arrays without shifting). > 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. > 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. 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. Kurt _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
