C compiler

[webmasterpdx]

I'm thinking more the OS memory map....not the hardware memory map. The hardware memory map can be obtained from the Core spec sure, but the OS memory map is HP's....like how are matrices stored or how to get at a spreadsheet cell from C.
I'm not thinking of producing custom OS (though you could run linux on it).
If I wanted linux, I could buy a C.H.I.P. board for $9 with wifi, bluetooth, running at 1GHz and it already has linux running on it.
I want a super math machine. I've done programming on TI calculators in the past and ran into problems with them not running fast enough. I was able to speed them up by using vector operations by adding lists of numbers, etc, etc.. but to get true speedups I needed to use C or assembler.
The latter is what I want to achieve....being able to write C code callable from a standard program that implements an algorithm, taking input from PRIME structures (number, matrix, list, spreadsheet, etc.) and outputting the results to PRIME structures. Now it might be doable by allocating a matrix and moving data from the other structures into the matrix, sending the matrix into the C program, getting the results in another matrix, and moving data from the matrix to the other prime structures.
We'd need a way to get the C program into the prime. We'd need a way to access the prime's malloc function to load it into RAM

Note that the flash is NAND which is not execute in place, so all programs run in RAM.

I'm thinking aloud here as I'm typing and am thinking that we could compile the code and convert the machine binaries to a matrix format....maybe as a program with an initialized matrix (in text) which is loaded in as a program, and finding a way to run code at the address of the matrix... You know, with this paradigm, all I need is the screen buffer memory addresses (which we have or can get fairly easily). The rest can be passed in as a matrix with the transfer being done in HP PPL. So all we gotta figure out is how to execute from the address of an array of bytes. I could write a utility a part of the build tools to convert the binary to the array, and I'd have to handle local stack variables...just create a dummy stack as part of the array/matrix. It'd be slower to start up, but this programming is for stuff that spends a long time in the algorithm or is trying to get access to some hardware feature (like the 2D graphics engine, which is currently not being used). Could also be used to communicate through wifi.

BTW, I was looking at the formats of the files in the binary distribution from HP. There is one (the app.dat one) that I was able to mount as a fat16 format, and it contained winCE dlls!!! What are these used for? Do these go into the prime? Then the master.dat file isn't any known disk format.... hard to figure out much from that.

Also, you mentioned that your example used the Linux tools. I got them running under cygwin on windows. They might also run under DOS. There are eclipse versions out there too that could be made to work, but I'm a VIM person (don't like eclipse).

On the subject of Jazelle, this core was the first to implement this so it actually got support. There is a JVM that supports jazelle for this core supplied for free by Sun/Oracle....called Phoneme. Google phoneme JVM. It's mostly for phones running J2ME. Personally, it really doesn't offer any advantages over the PRIME programming language other than running or easily converting existing apps on android or blackberry.

Thanks for the feedback. Anyone interested should speak now or forever hold your peace :-)

Fun stuff :-)