It will be a great day when GT.M is ported to a handheld. To port will require either an ARM compiler and runtime system to be written, or will require a GT.M interpreter to be written.
To deal with a new OS (WinCE or PalmOS) will require additional work. This is work that we would dearly love to do some day, when we can find some funding.
Meanwhile, you can run GT.M in your hand with an industrial handheld PC, or one of those Espresso machines, which is about the size of a Walkman -- no built in visual user interface, unfortunately.
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How could we get started on development of a GTM compiler and runtime for Linux ARM? That looks to me to be the most promising handheld platform for a port of GTM since Linux is already running on several ARM handhelds, including Compaq iPaq and Sharp Zaurus.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In a nutshell, porting to UNIX on a new platform such as ARM Linux requires retargeting the compiler. The compiler has a portable front end that translates M to intermediate code for a hypothetical stack architecture machine and a back end that translates the intermediate code to object code for each target machine. Much of the functionality is accomplished by a form of threaded code, in which the object code sets up parameters and calls low level functions that in effect create a GT.M virtual machine. There is also a dynamic linker.
So, for a UNIX like operating system, porting GT.M includes:
1. Rewriting the code generator (this includes dealing with things such as register allocation, calling conventions, stack frame layout, etc.).
2. Rewriting the low level routines.
3. Rewriting the dynamic linker.
4. Putting it all together (packaging).
5. Testing.
I would like to say that there is an excellent tome that lays it all out cookbook fashion. Alas, I cannot. So, the best way to get started would be to go through the current GT.M source code and grok it.
If you feel, or anyone else feels, ambitious enough to attempt such task, perhaps the best thing would be to spend a week in Malvern, PA with the GT.M development team. Perhaps setting up a cross reference with something like LXR (http://sf.net/projects/lxr) or mapping the call graph with gprof and VCG (see http://www.ida.liu.se/~vaden/cgdi\) would be another way to get started. We would certainly be willing to create a ARM port disucssion forum at Source Forge, and to answer questions posted there in a timely fashion.
I don't think a port is something that can be approached lightly. On the other hand, it's only a "small" matter of programming! Although GT.M's internal comments are somewhat sparse (but improving!), the language subsystem is reasonably well structured, without all the performance enhancement heuristics that complicate the database run time system..
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Folks,
Has anyone attempted/suceeded in porting GT.M to Windows CE?
How about a port to Linux on ARM for Compaq's iPaq or Sharp's new Zaurus handheld? That should be a much easier port. See http://www.handhelds.org
It will be a great day when GT.M is ported to a handheld. To port will require either an ARM compiler and runtime system to be written, or will require a GT.M interpreter to be written.
To deal with a new OS (WinCE or PalmOS) will require additional work. This is work that we would dearly love to do some day, when we can find some funding.
Meanwhile, you can run GT.M in your hand with an industrial handheld PC, or one of those Espresso machines, which is about the size of a Walkman -- no built in visual user interface, unfortunately.
-- Bhaskar
How could we get started on development of a GTM compiler and runtime for Linux ARM? That looks to me to be the most promising handheld platform for a port of GTM since Linux is already running on several ARM handhelds, including Compaq iPaq and Sharp Zaurus.
Jim --
In a nutshell, porting to UNIX on a new platform such as ARM Linux requires retargeting the compiler. The compiler has a portable front end that translates M to intermediate code for a hypothetical stack architecture machine and a back end that translates the intermediate code to object code for each target machine. Much of the functionality is accomplished by a form of threaded code, in which the object code sets up parameters and calls low level functions that in effect create a GT.M virtual machine. There is also a dynamic linker.
So, for a UNIX like operating system, porting GT.M includes:
1. Rewriting the code generator (this includes dealing with things such as register allocation, calling conventions, stack frame layout, etc.).
2. Rewriting the low level routines.
3. Rewriting the dynamic linker.
4. Putting it all together (packaging).
5. Testing.
I would like to say that there is an excellent tome that lays it all out cookbook fashion. Alas, I cannot. So, the best way to get started would be to go through the current GT.M source code and grok it.
If you feel, or anyone else feels, ambitious enough to attempt such task, perhaps the best thing would be to spend a week in Malvern, PA with the GT.M development team. Perhaps setting up a cross reference with something like LXR (http://sf.net/projects/lxr) or mapping the call graph with gprof and VCG (see http://www.ida.liu.se/~vaden/cgdi\) would be another way to get started. We would certainly be willing to create a ARM port disucssion forum at Source Forge, and to answer questions posted there in a timely fashion.
I don't think a port is something that can be approached lightly. On the other hand, it's only a "small" matter of programming! Although GT.M's internal comments are somewhat sparse (but improving!), the language subsystem is reasonably well structured, without all the performance enhancement heuristics that complicate the database run time system..
-- Bhaskar