On 1/1/13 3:43 AM, BGB wrote:
here is mostly that this still allows for type-tags in the
references, but would likely involve a partial switch to the use of
64-bit tagged references within some core parts of the VM (as a partial
switch away from "magic pointers"). I am currently leaning towards
putting the tag in the high-order bits (to help reduce 64-bit arithmetic
ops on x86).
One idea I heard somewhere (probably on some Squeak-related list several
years ago) is to have all objects stored as floating point NaN instances
(NaN == "Not a Number"). The biggest bottleneck in practice for many
applications that need computer power these days (like graphical
simulations) usually seems to be floating point math, especially with
arrays of floating point numberls. Generally when you do most other
things, you're already paying some other overhead somewhere already. But
multiplying arrays of floats efficiently is what makes or breaks many
interesting applications. So, by wrapping all other objects as instances
of floating point numbers using the NaN approach, you are optimizing for
the typically most CPU intensive case of many user applications.
Granted, there is going to be tradeoffs like integer math and so looping
might then probably be a bit slower? Perhaps there is some research
paper already out there about the tradeoffs for this sort of approach?
For more background, see:
http://en.wikipedia.org/wiki/NaN
"For example, a bit-wise example of a IEEE floating-point standard
single precision (32-bit) NaN would be: s111 1111 1axx xxxx xxxx xxxx
xxxx xxxx where s is the sign (most often ignored in applications), a
determines the type of NaN, and x is an extra payload (most often
ignored in applications)"
So, information about other types of objects would start in that "extra
payload" part. There may be some inconsistency in how hardware
interprets some of these bits, so you'd have to think about if that
could be worked around if you want to be platform-independent.
See also:
http://en.wikipedia.org/wiki/IEEE_floating_point
You might want to just go with 64 bit floats, which would support
wrapping 32 bit integers (including as pointers to an object table if
you wanted, even up to probably around 52 bit integer pointers); see:
"IEEE 754 double-precision binary floating-point format: binary64"
http://en.wikipedia.org/wiki/Binary64
does sometimes seem like I am going in circles at times though...
I know that feeling myself, as I've been working on semantic-related
generally-triple-based stuff for going on 30 years, and I still feel
like the basics could be improved. :-)
Meanwhile I'm going to think about Alan Kay's latest comments...
--Paul Fernhout
http://www.pdfernhout.net/
====
The biggest challenge of the 21st century is the irony of technologies
of abundance in the hands of those thinking in terms of scarcity.
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
