> On Fri, 13 May 2005, Andrzej Ritz wrote:
>
> > Linux runs on a number of Palmtops, some of which are listed on the
> > following site:
> >
> > http://www.linux-on-laptops.com/palmtops.html
> >
> > There is also a commercial version of Linux for embeded applications
> > (see the attached pdf). Would porting mini-poplog to platforms like
> > uClinux be such a big task?
>
> Because poplog compiles itself, both when the core system is built
> and when user code is incrementally compiled to machine code, nobody
> else's compiler can be used to port it, e.g. gcc, etc., though
> system assemblers and linkers are used for rebuilding poplog.
But ...
I proposed the following to some friends. It got a few raised eyebrows,
but is possible in principle.
The poplog incremental compiler goes through a pop-VM stage, before
final compiling to machine code. There are "hooks" to trap this stage
(there is a library which lets you see the VM code as text, when you
compile a procedure).
So: define a Pop-VM bytecode (cf JAR files for Java). Write a byte-code
interpreter. This is, actually, the easiest bit. (As some of you know,
I've done it before for a pop11. For poplog, there are some additional
complications for: special prolog VM instructions and poplog "processes",
but I don't see any other special difficulties.)
If you do this in, say, Java, you don't even need to write a garbage
collector.
Now, write your byte-code generator (in the full poplog) using the hooks
I mentioned above. Voila! You can compile and export simple pop11
programs, and run them on any machine which can run Java.
I wanted to do this so that I could get a "Setpop" prompt on my mobile
phone, and then type '2+2=>' to get '** 4'.
Porting auto-loadable libraries would be easy: just compile them to
bytecode. The real work would be in re-creating all the poplog built-in
functions, particularly those that use pop11 "system dialect". (The others
could also be ported as ordinary Pop-VM bytecode with much less effort.)
Doing everything in the easiest possible way would result in something
that ran very slowly. You could speed it up by gradually replacing as many
of the "bytecode" built-in procedures as you wanted. BUT if I'm worried
about speed, why am I running it on a mobile phone instead of a real
computer?
And the real, serious, point to all this is not to be able to add 2+2
(I already know the answer) but because it would be instantly and easily
portable to any platform. (For real, instead of "toy" applications, it
might then become worthwhile to write a byte-code interpreter in C, or
perhaps C++, with more of an eye to efficiency.)
I'm not sure if it would make it any easier to do a proper full port of
poplog, but it should allow you to develop the cross-compiler on the
target machine. And, probably, the speed of the cross-compiler is not
going to be a big issue.
> If the palmptop has an intel x86 type cpu or equivalent (like AMD) then
> I assume something like Steve Isard's port to mini-linux should work.
> see
> http://www.cs.bham.ac.uk/research/poplog/mini-linux-pop/
>
> Other relevant questions would be amount of memory available, size of
> hard drive or equivalent, etc.
If you look at the specs for some of the latest mobile phones
(let alone palmtops) there is no reason to restrict yourself to a mini
version of poplog. There would be plenty of room for a full installation.
It's a bit mind-boggling.
(I've been told that there are some artificial security
restrictions on what Java progs are allowed to do in a phone. But since
it is possible to write and run games ...)
> I am also copying to pop-forum in case someone on the larger list
> wants to comment.
Well, I've commented. Not a very useful comment, perhaps, since it was
a response about not being able to port using gcc: there could be a way
which also would allow ports to platforms with no access to a native
compiler or to machine code.
But in answer to the real question: a conventional port is certainly
possible,
and might be less of a big task than the recent port to the Mac since there
are already Linux Poplogs. But still a lot of work.
Jonathan
|