+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: static recompilation of the HP-15C ROM (/thread-675.html)
static recompilation of the HP-15C ROM - robert rozee - 02-14-2014 04:39 PM
nope, i've not done it, but would like to suggest it is a good idea. for an example of what is possible, have a look here:
http://www.pagetable.com/?p=48
essentially static recompilation involved writing a translation program that knows how to decompose individual compiled instructions for a source processor, and recreate equivalent 'instructions' built out of C code, said instructions operating upon a set of 'registers' that exist as C variables. as an example, in very bad C code (my C is weak):
int A, R1; /* source processor registers */
bool ZF; /* source processor flags */
...
/* instruction at address 1234 */
R1=A ; /* move contents of A into R1 */
ZF=(A==0); /* sets the zero flag if A was zero */
in the above example A and R1 are two registers in the source processor, and the two line of C code are the C translation of the instruction to move the contents of A into R1 and then set the zero flag true of A was zero.
the recompiler has to either be clever enough to identify blocks of data, or be guided around them. access to hardware (keyboard, display, timers, etc) needs to generate calls to a set of external library routines that are specific to the new target. jumps and branches are handled with 'goto' statements, making the resulting C code is very much a can of worms; certainly not something that is easily maintained.
BUT, the output can be recompiled on ANY platform that supports a suitable C compiler. all one has to do is rewrite the small set of library routines to handle I/O, etc. plus, it is relatively easy to handle adding enhancements and extensions.
for example, in the case of the 15C ROM there is a block of code that handles display of a program listing. the display is filled with <address> - <key codes>. the end of this block can easily be patched to replace the key codes with the english instruction. so "001 - 42,21,11" displays as "001 label A" with just a little bit of C code added in (yep, the above is 11C code).
are there any takers out there?
it could be a neat open-source project. all that needs to be published is the static recompiler, ready to run, and a set of example library routines. the individual can then provide the 15C ROM image to create their own recompilation and start customizing. for those of us with a hardware bent, creating our own 15C becomes just a matter of hooking up a 16x1 matrix display and some buttons to a suitably large atmel or pic processor, or compiling for a PC or mac if so inclined.
rob :-)
RE: static recompilation of the HP-15C ROM - Mike Morrow - 02-14-2014 06:22 PM
I'd have thought that the thirst for re-incarnated HP-15C machines would have been sated by the infamous HP 15C LE and the more faithfully emulated (but much less practical to use) DM-15.
RE: static recompilation of the HP-15C ROM - J-F Garnier - 02-16-2014 10:39 AM
When I started to work on emulation several years ago, I thought about this kind of technic. But it's quite difficult and requires a lot of memory. It's much more practical to use opcode emulation.
For these classic calculators, speed is not a concern at all and opcode emulation works very well.
I would not call the HP 15C LE infamous at all. It's a nice machine, of historic interest - especially for me who never owned a real HP-15C, and honestly the bugs are of minor importance for the usage I can do nowadays of such classic machines. I'm much more annoyed by the archaic key code display in prgm mode, but that's how the HP 15C worked.
RE: static recompilation of the HP-15C ROM - robert rozee - 02-16-2014 11:33 AM
given that the 15C rom contains, what, a few thousand instructions, the result of static recompilation would probably easily fit within the available flash of many modern controllers. the pic32mx150, for instance, has 128k of flash available. i reckon this would be enough. if the flash is there, there is no good reason not to use it if it makes the job easier.
and the advantages are several:
- code that can be added to without need for trapping or worrying about the IP address, in order to fix bugs or add enhancements. it is possible to add in C code between the execution of the original instructions, and even modify individual instances of an instruction if needsbe. over time, some blocks of instructions may benefit from being hand-translated into 'pure C'. as i said before, moving to displaying instruction mnemonics instead of key codes becomes quite achievable.
- a source base that arguably side-steps copyright issues, in that it does not contain a copy of the original rom in any form that can be directly recognized or extracted. this is how microsoft basic gets away with being freely distributed. the code ends up representing just the algorithms.
- the whole development process can be divided up into a number of stages and blocks that can be achieved across many members of a group. quite literally, once the data structures are decided upon, each saturn instruction can be coded in C by a different person. it then becomes a true community effort with no need for a single author.
tasks might be:
- design data structures,
- create one or more I/O libraries (one for each desired platform),
- a team to work on instruction decoding for the static recompiler
- a number of individuals to re-encode instructions as blocks of 'C' code
rob :-)