▼
Posts: 260
Threads: 32
Joined: Jul 2005
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.
So perhaps a compiler could use the potential of the 33s?
As I don't have a 33s, what are your opinions?
▼
Posts: 536
Threads: 56
Joined: Jul 2005
can you post a short example of an input program and its output. thanks.
▼
Posts: 260
Threads: 32
Joined: Jul 2005
//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!
pfibo Proc ( vNuma , vNumb ) ;
DECLARE vResult ;
DO
vResult = vNuma + vNumb ;
vNuma = vNumb ;
vNumb = vResult ;
END pfibo ;
pMain Proc ( ) ;
DECLARE vStart ;
DECLARE vNext ;
DO
vStart = 1 ;
vNext = 1 ;
IF vStart == vNext THEN
pfibo ( vStart , vNext ) ;
END ;
vStart = 2 ;
PUT vNext ;
END pMain ;
code after pass14:
1 LABEL pfibo
2 RCL R1
3 RCL + R2
4 STO R3
5 RCL R2
6 STO R1
7 RCL R3
8 STO R2
9 RETURN (end of pfibo )
10 LABEL pMain
11 1
12 STO R1
13 1
14 STO R2
15 RCL R1
16 RCL R2
17 X==Y?
18 -27
19 STO I
20 GOTO I
21 2
22 STO R1
23 #PUT
24 RCL R2
25 #UNPUT
26 RETURN (end of pMain )
27 GSB pfibo
28 -21
29 STO I
30 GOTO I
-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
...
▼
Posts: 74
Threads: 10
Joined: Jan 1970
Essentially the same message but in a more readable form :-)
123 to delete
//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!
pfibo Proc ( vNuma , vNumb ) ;
DECLARE vResult ;
DO
vResult = vNuma + vNumb ;
vNuma = vNumb ;
vNumb = vResult ;
END pfibo ;
pMain Proc ( ) ;
DECLARE vStart ;
DECLARE vNext ;
DO
vStart = 1 ;
vNext = 1 ;
IF vStart == vNext THEN
pfibo ( vStart , vNext ) ;
END ;
vStart = 2 ;
PUT vNext ;
END pMain ;
code after pass14:
1 LABEL pfibo
2 RCL R1
3 RCL + R2
4 STO R3
5 RCL R2
6 STO R1
7 RCL R3
8 STO R2
9 RETURN (end of pfibo )
10 LABEL pMain
11 1
12 STO R1
13 1
14 STO R2
15 RCL R1
16 RCL R2
17 X==Y?
18 -27
19 STO I
20 GOTO I
21 2
22 STO R1
23 #PUT
24 RCL R2
25 #UNPUT
26 RETURN (end of pMain )
27 GSB pfibo
28 -21
29 STO I
30 GOTO I
-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.
For the HP-41 or the emulated 42, a binary output would be useful...
Any plans for RPL?
▼
Posts: 123
Threads: 7
Joined: Jan 1970
>Any plans for RPL?
As a target, or the language to write the compiler in? *g*
nice idea.
.
Posts: 2,247
Threads: 200
Joined: Jun 2005
How will you transfer the complied code to the HP33s?
▼
Posts: 785
Threads: 13
Joined: Jan 2005
"...and key the output 1 : 1 into the calc"
(-:
[VPN]
▼
Posts: 2,247
Threads: 200
Joined: Jun 2005
:-<
I was hoping for some "magical" way to input the code. I do like the concept in general!
Namir
Posts: 260
Threads: 32
Joined: Jul 2005
Well, I have posted some example code. My compiler is rather a proof-of-concept, so I haven't tested its output.
If enough people are interested, we can make our own grammar and I will write everything from scratch. Ideas for code-optimization are also welcome!
Klaus
Posts: 2,309
Threads: 116
Joined: Jun 2005
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?
▼
Posts: 260
Threads: 32
Joined: Jul 2005
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.
Greeting, Klaus
Posts: 2,247
Threads: 200
Joined: Jun 2005
How common is the use of GOTOs for RRB jumps? I have always avoided that kind of GOTO because the program can become buggy if new commends are inserted. I always use labels with GOTOs.
Namir
▼
Posts: 260
Threads: 32
Joined: Jul 2005
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.
▼
Posts: 2
Threads: 1
Joined: Jan 1970
Klaus:
I think that your compiler is important.
When I wrote the "FOCALFREE" utility some months ago I was thinking about to write a compiler too.
Regards:
Alvaro Gerardo Suarez
(www.geocities.com/algesuar)
Posts: 1,755
Threads: 112
Joined: Jan 2005
Hi, Klaus:
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.
Sorry about that and best regards from V.
▼
Posts: 260
Threads: 32
Joined: Jul 2005
Hello Valentin,
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.
Well, at least I regained some practice in writing Compilers!
Klaus
▼
Posts: 2,247
Threads: 200
Joined: Jun 2005
Klaus,
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+).
Namir
|