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

[Rainer Joswig]

Am 31.10.2007 um 00:24 schrieb Gary Byers:

Thanks for your thoughts, Gary.

> 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.

Right. ;-)

> 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.

Ah, right, I forgot about that. 'Ralph' on the iPhone, there is an  
idea. ;-)
'Leibniz' ported to OpenMCL^h^h^h^h^h^h^h Clozure CL.

> 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.)

128MB RAM isn't that much, when there is the OS and other
applications, too. It would be interesting to know what
Apple did to keep the memory usage low - if they do provide
special features for that.

>  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.)

One would probably want to be compatible with Apple's touch version
of Cocoa and its usage of strings - if the target would be one
of those 'touch' devices.

> - 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 ...)

I'd say usually one would use ssh (or similar) to talk to such a device,
given that it has WLAN (or Bluetooth) and a working IP stack.
Don't know what the workflow of the SDK from Apple will be,
but I guess they have some offline Interface Builder. With
Op..., I mean Clozure CL one may want to work interactively.
So I guess it would be useful to have some of the development
information available at runtime on the device.

Another idea would be to reduce the Lisp a bit. No compiler for example.
That would leave the interpreter and some way to load
compiled code. Might or might not be useful.

> 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.

I heard that the current models might run up to something like 600Mhz.  
Probably
with variable speed. The main memory is 128 MB - the OS takes something,
there are also other apps using memory. Apple currently has problems
with Safari stability while playing music in the background - I heard
that a memory problem (not enough memory) is a problem.
Then there is also limited space for the applications in flash ram,
it seems - though I guess this can be configured. Generally I think
the touch devices should have plenty power for Clozure CL (!).
One also might need a custom on-screen keyboard with some
of the widely used Lisp characters ( (, ), #, ', .-, ..) .     ;-)

I would guess that the OS internals are similar to OSX on other
machines (exceptions, threading, network stack, ...).

Regards,

Rainer Joswig


>
>
>
> 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
>>
>>