[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: [Maxima] Re: Lisp vs. Java vs. C++ speed
From: |
Michael Koehne |
Subject: |
Re: [Gcl-devel] Re: [Maxima] Re: Lisp vs. Java vs. C++ speed |
Date: |
Mon, 12 Jul 2004 19:08:25 +0200 |
User-agent: |
Mutt/1.3.28i |
Moin Camm Maguire,
> I suppose the canonical way to do this is to make use of the two least
> significant bits in the pointer value on 32bit machines to hold the
> type information, but this seems quite expensive as each pointer
> indirection must be accompanied by a pointer truncation.
I dont think that it would be wise to do that - we would miss the
FIRSTWORD in the object and any security, to deceide, if its a cons.
One trick to preserve security and address space, would be to say
that 'missalligned' pointers are special, so a vapor ware 32bit
Lisp system might look like :
(unsigned int)object & 3 == 0 ->
object with FIRSTWORD
(unsigned int)object & 3 == 1 ->
(object)((unsigned int)object-1) is native Pascal string
(unsigned int)object & 3 == 2 ->
(object)((unsigned int)object-2) is native C string
(unsigned int)object & 3 == 3 ->
(object)((unsigned int)object-3) is cons
but to rewrite every code, would be a lot of work, with unknown
side effects, as FIRSTWORD does not only contain t, but also flag
and s,m. The result wont be GCL anymore, but incompatible to every
piece of GCL/C interface written so far.
Bye Michael
--
mailto:address@hidden UNA:+.? 'CED+2+:::Linux:2.4.22'UNZ+1'
http://www.xml-edifact.org/ CETERUM CENSEO WINDOWS ESSE DELENDAM