[Openmcl-devel] Thoughts? OpenMCL on ARM processors?

[Gary Byers]

Not saying anything about business issues (market, funding, or other
business issues): I think that the ARM is a neat architecture (or
a neat family of architectures) and that it'd be equally neat to run
OpenMCL^H^H^H^H^H^H^HClozure CL on PDAs and smart phones and other
ARM-powered devices.

Apple's Dylan implementation originally targeted the ARM (which was
used in the Newton), so there's a certain amount of closure (that's
spelled with an 's' ?  Who knew ?) involved as well.

The current PPC32 heap image is around 10MB in size; I'd -guess- that
an ARM image would be roughly equvalent in terms of code density to
the PPC32, and you'd probably need 2-3X that in order to run at all
comfortably with a few threads.  (As I understand it, using more
memory tends to increase power consumption and limit battery life, so
you'd want to whack that number down as much as possible.)  There are
some obvious areas:

- I believe that the use of 32-bit (UCS-4 or UTF-32) characters
in strings is the right thing for modern desktop systems; it
may not be the right thing for a PDA (and using a 16-bit subset
the covered the BMP would save something close to 2MB.)  Market
issues would influence whether it's practical to inconvenience
cuneiform users ("No, Gilgamesh!  Use the other stylus on your
PDA!"), but it's almost certainly the case that strings would
need to be encoded more compactly.  (I believe that CLISP uses
32-bit strings for the same reason that OpenMCL does, but that
it keeps a lot of things that're known to be immutable and that
fit in an 8-bit encoding in a more compact internal representation;
something like this may be another worthwhile time/space tradeoff.)

- There are some vectors that're used to map constant slot names to
slot definition objects that can get fairly large; these vectors are
often sparse and a few extra accesses (time) could save a lot of
space.  Adding the MOP (or the fairly large subset of it that's
implemented) to OpenMCL a few years back caused the image size
and memory requirements to grow a bit (I don't remember the numbers,
but it was less dramatic than the 32-bit string change.)

- A few years ago (around the time that it finally sunk in that
more people were using OpenMCL on desktop systems than in spacecraft
or other embedded systems) the image started including debugging
info (local variable names and stack/register addresses, source
file info, some doc strings) that had been excluded.  From what
I remember, that added up to about 1MB.

Some of this also depends on what the development model is: do
you develop on (and keep debugging info on) a desktop system, or
is it practical and desirable to develop on ARM-based systems ?
(If the latter, it might be worth investing in one of those
little Bluetooth keyboards ...)

For the first few years that I worked on it (around 2001-2002),
all of the OpenMCL work that I did was done on a 120MHz 
PowerMac 8500 with 48MB of RAM and on a 233Mhz Rev A iMac with
64MB.   That wasn't -that- long ago, and your average iPod
(or wristwatch) probably has more memory/horespower than either
of those machines did.


On Tue, 30 Oct 2007, Rainer Joswig wrote:

> Hi,
>
>  I'm a bit curious to hear if anybody has thoughts about this topic.
>
> ARM processors are extremely widely used. They offer RISC design with
> a low-power implementation.
>
> As I understand the iPhone and the iPod touch are both ARM-based and
> they are running
> a customized version of OSX. Apple is currently not providing a
> software development kit,
> but has announced that there will be some form of SDK starting in
> February next year.
> People have been able to write software for these devices, which
> currently is not
> wanted by Apple.
>
> Both devices have 128MB RAM and a minimum of 8GB flash based disk.
>
> AFAIK no popular native code compiling Common Lisp can compile to ARM
> instructions.
>
> Maybe Gary has an opinion about this? How different would a backend
> for the ARM
> processor (say, similar to those used in the iPhone and iPod touch) be
> from the
> 32bit PPC backend? Would it be easier or more difficult than a 32bit
> Intel backend?
>
> CCL, MACL, ... were running in very little memory years ago. Wouldn't
> it be
> a good starting point for a native code compiler for ARM-based OSX
> machines?
>
> It is unknown how much future ARM processors will have in mobile
> Apple computers, since it might be possible that Intel will have
> useful low-power x86 machines. But it seems that the infrastructure
> for low-power ARM-based devices is quite good right now and
> Apple has two devices that will be sold in large quantities.
>
> Does anybody has spare cycles to comment on this?
>
> Regards,
>
> Rainer Joswig
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>