I have written a compiler that takes a deviceinfo file and a sourcecode file as input and outputs RPN-code. With the deviceinfo file it should be configurable for any device that understands RPN.

My vision was that you write a program in a High-level language, and compile it. The compiler notes the program lines occupied by the program in the deviceinfo file, so you can compile your programs separately. The compiled programs can then be typed into the calc. You can write your library of commonly used programs in a high-level language, compile the programs you need and key the output 1 : 1 into the calc.

Unfortunately, the calculators I own do not have a 'GOTO linenumber' command, so the Index register has to be loaded with the negative linenumber and a GOTO I has to be executed. This makes the code bigger than I thought.

Now I read coomplaints about the new 33s, saying "it has sooo much storage, and only 26 labels to use". This might be a good target for the Compiler, because the compiler emits big code with little Labels.

//Testfile for iqasm compiler
//Coding rules:
//1. hit space after each symbol ( because the scanner is simple )
//2. Names of Variables have to start with 'v' ( because the scanner is simple )
//3. Names of Procedures have to start with 'p' ( because the scanner is simple )
//4. Numbers can be int or float, any number accepted by Java is valid.
//5. Parameters are call-by-reference. Thus a procedure can "return" values.
//6. Procedure and variable names are not checked well. Do not name a variable v1&%2!

-Label names have to be replaced
-PUT has to be implemented with information from the device-file
-Numbers are currently one-line, have to be splitted for my calcs (33s too?)
-Optimization of :
...
STO REG1
RCL REG1
...

//Testfile for iqasm compiler
//Coding rules:
//1. hit space after each symbol ( because the scanner is simple )
//2. Names of Variables have to start with 'v' ( because the scanner is simple )
//3. Names of Procedures have to start with 'p' ( because the scanner is simple )
//4. Numbers can be int or float, any number accepted by Java is valid.
//5. Parameters are call-by-reference. Thus a procedure can &quot;return&quot; values.
//6. Procedure and variable names are not checked well. Do not name a variable v1&amp;%2!

-Label names have to be replaced
-PUT has to be implemented with information from the device-file
-Numbers are currently one-line, have to be splitted for my calcs (33s too?)
-Optimization of :
...
STO REG1
RCL REG1
...
to
...
STO REG1
...

I didn't type it in, I just had a look at the source; cut&paste did the rest.

Quote:
Unfortunately, the calculators I own do not have a 'GOTO linenumber' command, so the Index register has to be loaded with the negative linenumber and a GOTO I has to be executed.

On most (all?) of the earlier calculators that had this feature, called Rapid Reverse Branching, the number in the accumulator was not directly related to the line number of the target, but rather a relative count of lines from the GOTO to the target. In other words, if the I register contained -8 and the instruction at line 37 was GTO I, it would branch to line 29. Obviously a compiler can take this into account, though if you edit a program using RRB you may have to make a lot of adjustments.

The HP-41C family does not have this feature, so it wouldn't be useful there. Does the 33S actually have RRB? Did the 32S and 32SII?

Well, I didn't know about that different behavior. I used the behavior from the 11c, where a negative number describes the absolute address.
With different machines, I can describe the GOTO-behavior in the device-info and thus emit correct code.

The program can become buggy, if you edit it by hand. If you add something to the high-level language and compile it, the code [should be] or [is] correct.

One more thing about my compiler:
The parser generates some RPN code, and this code is optimized later. (You can still see the #PUT and #UNPUT that have to be optimized). The RPN code goes throough several optimization passes:
1. If supported, add RECALL-arith
2. Optimize procedure calls
...
10. Move the fixups for if to end of program
...
13. Add line numbers and replace GOTO-labels
14. Use index Register for GOTO

The optimization can also take place if the code is not generated by a parser, but written by a user. True, but using the stack the user can pack the code tighter, but one could think of a RPN-language containing higher-level commands for GOTO, IF, WHILE,... and is then optimized.

It's quite a bold and worthy move on your side to
attempt this, but unfortunately the HP33S' GOTO instruction
*cannot* branch to line numbers, only to labels, so your innovative
approach won't work for this particular machine.

this morning i downloaded the 33s manual and noticed what you mentioned. Unfortunately the GOTO .nnn is not programmable. Maybe someone will find a way to drop this statement in program memory (sort of synthetic programming). I also read some manuals on the CD-Set and was surprised by differences in calculators.

I certainly applaud your effort. My suggestion is to target popular vintage HP calculates like the HP41C and HP42s. These calculators have good emulators that can read source code and convert into .raw files. This feature with your compiler will be excellent combination. In the case of the HP42s you can kee the name of the variables since the 42s support named variables (like the 48SX/GX, 49G, and 49G+).