Re: Portability

[rmb]

Swarm data types already offer sufficient guarantees for C-level portability.
We guarantee that int's and unsigned's are at least 32 bits, and I assume
that our floating point formats are IEEE on every architecture we run on
(correct me please, if there's any architecture on which I'm wrong).  C
offers no guarantees on fixed-point overflow, so you just have to make sure
that the limits of an integral type are sufficient for whatever you put in
them.

If there's any need for a portability guarantee on longer int's (64-bit) we
can likely provide those, too, courtesy of gcc's "long long" int types.  As
we port to 64-bit architectures (in progress) we can document exactly what
further portability assumptions you can make, but the ones we have are
likely sufficient for any model.

We do need at least to document the number of bits of precision that can be
guaranteed out of our random number generators, and make sure this is exactly
the same as implemented on all architectures, but that can be done within the
existing interfaces.  So I don't see a need to define a whole series of
Swarm-specific basic data types, which would only increase the learning
mismatch from those who already know C.

Wrt to the Java discussion, portability is not the main issue.  The
expressibility of Java's object model and the ability to perform generic
dispatch of our scheduled actions are much bigger issues.  Even with a fast
Just-In-Time (jit) compiler for Java on some architectures, I've heard
nothing about the speed that could be delivered with the relatively
heavy-weight "reflection" mechanisms that Java just added to enable such
generic actions.  All our low-level data structures, for collections, storage
allocation, and activity execution, could also be implemented within Java
only in significantly more cumbersome and expensive forms, so far as I can
tell.

This isn't to say that Java couldn't play an important role with Swarm.
I'd like to see Java-based user interfaces as an optional alternative to the
TCL/Tk framework.  These user interfaces would still execute the core
compiled code of a Swarm model as native C modules, which Java fully
supports.  An intermediate step like this would allow building experience
with the Jave runtime environment without compromising all the things that
have to go on inside a Swarm model.

Newbie enthusiasm of an self-admitted, incipient "language bigot" [insert
grin here] shouldn't deflect attention that Swarm's scheduled action
structures are in many respects becoming their own self-interpreted program
structure, for which the main criterion of an execution "back-end" is the
ability to perform the heavy cycle-crunching execution of a complex
concurrent model (perhaps distributed on parallel hardware) as efficiently
as possible.  We still have much further to go toward this on a C
execution base; Java right now would move us backward rather than forward.

Roger Burkhart