gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]