 |
Newsgroups: comp.lang.lisp
From: Duane Rettig <du...@franz.com>
Date: Wed, 21 Aug 2002 00:00:05 GMT
Local: Tues, Aug 20 2002 8:00 pm
Subject: Re: Common Lisp wish list item
r...@fdy2.demon.co.uk (Robert Swindells) writes: Well, yes, but fixnums in FranzLisp contained even fewer bits than on > Erik Naggum <e...@naggum.no> wrote in message <news:3238779012022126@naggum.no>... > > I really wish fixnums were the natural machine word. > PDP-10 Maclisp and Franz Lisp used bibop rather than tag bits to type > This meant that pointers as well as fixnums could be passed straight more modern CL implementations (I think that the range was -1023 to 1022, or something like that). In fact, a section of memory was explicitly allocated for fixnums, so that no other lisp objects could be allocated at that location (so that the gc and type-of could not become confused as to whether or not a bit pattern was a fixnum or a lisp object of some other type. And since fixnums have magnitude and order, it was not just a case of allocating new pages of fixnums when needed. The implication to this is that if you cover all of the 32-bit space > On a modern CPU with huge penalties for cache misses, tags make more The modern CLs do not use memory accesses for fixnums; they are > sense as they will always be in the cache along with the pointer that > they type. Needing to load a cacheline for the pointer as well as one > for part of the type table would really reduce cache efficiency. immediates. Therefore going back to bibop (in hashed-address form) for fixnums carries with it an automatic penalty with it, no matter how fast your cache. > I have always wished that more effort had been made to try adding The entire reason for modern lisps moving away from special-purpose > hardware features to speed up bibop. All of the lispms and the RISC > chips that I know of (SOAR, SPUR and SPARC) used tags. > I started building an add-on board to the AtariST to do hardware bibop hardware is because such hardware cannot compete in the long term. There is no way for a LispM company to devote close to the same order of magnitude of manpower to keep the performance curve up with GP hardware. However... if you can use existing GP hardware to advantage: > In a modern CPU there are usually several spare bits in a page table This is a good idea, as long as > entry. I would like to see some way of using them to store the type > of objects in that page. 1. The pte bits truly are spare (and are likely to stay that way) 2a. Your Operating system allows you to use these bits, or > It would be nice to have a user mode instruction that would treat the Most architectures do indeed have such instructions, but some of them > contents of a source register as a pointer and load the type bits for > it's page table entry into a destination register. regard such instructions as supervisor-only, and thus only accessible by a LispOS kernel, or by explicit kernel support in whatever Unix kernel you are operating under. -- You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||