breaking the limits of the 33s with a compiler?
#1

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?

#2

can you post a short example of an input program and its output. thanks.

#3

How will you transfer the complied code to the HP33s?

#4

"...and key the output 1 : 1 into the calc"

(-:

[VPN]

#5

//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
...

#6

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

#7

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?

#8

:-<

I was hoping for some "magical" way to input the code. I do like the concept in general!

Namir

#9

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

#10

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

#11

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.

#12

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 &quot;return&quot; values.
//6. Procedure and variable names are not checked well. Do not name a variable v1&amp;%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?

#13

>Any plans for RPL?

As a target, or the language to write the compiler in? *g*

nice idea.

.

#14

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.

#15

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

#16

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

#17

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)



Possibly Related Threads…
Thread Author Replies Views Last Post
  41-MCODE: Breaking the FAT barrier. Ángel Martin 0 895 09-03-2012, 06:31 AM
Last Post: Ángel Martin
  WP34S: New compiler to be tested Marcus von Cube, Germany 15 3,410 09-02-2012, 02:47 AM
Last Post: Walter B
  wp 34s exponent limits? wildpig 26 5,703 08-28-2012, 02:48 PM
Last Post: Marcus von Cube, Germany
  Limits of Indirect Addressing on the WP34S Namir 11 3,034 08-01-2012, 11:53 PM
Last Post: Namir
  WP34S - Flashing Limits Les Wright 13 3,174 03-12-2012, 10:53 AM
Last Post: Marcus von Cube, Germany
  HP-41 Focal Compiler/Decompiler MichaelG 0 891 02-14-2012, 11:30 AM
Last Post: MichaelG
  WP34s build compiler David Griffith 19 4,227 01-06-2012, 08:49 AM
Last Post: Marcus von Cube, Germany
  OT: Sharp PC-1270 BASIC Compiler V3.3 XYZT 1 1,116 12-18-2010, 05:02 PM
Last Post: Thomas Okken
  Breaking news. Pal G. 4 1,342 09-11-2009, 08:00 PM
Last Post: Raymond Del Tondo
  Is this Ebay auction breaking any copyright? Mark Edmonds 75 13,909 07-14-2009, 05:43 PM
Last Post: Les Bell

Forum Jump: