The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

breaking the limits of the 33s with a compiler?
Message #1 Posted by Klaus on 30 Mar 2005, 9:27 a.m.

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?

      
Re: breaking the limits of the 33s with a compiler?
Message #2 Posted by hugh steers on 30 Mar 2005, 11:01 a.m.,
in response to message #1 by Klaus

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

            
compiler- (long)
Message #3 Posted by Klaus on 30 Mar 2005, 12:01 p.m.,
in response to message #2 by hugh steers

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

                  
Re: compiler- formatted listing
Message #4 Posted by Marcus von Cube on 31 Mar 2005, 1:32 a.m.,
in response to message #3 by Klaus

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?

                        
Re: compiler- formatted listing
Message #5 Posted by . on 31 Mar 2005, 2:17 a.m.,
in response to message #4 by Marcus von Cube

>Any plans for RPL?

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

nice idea.

.

      
Re: breaking the limits of the 33s with a compiler?
Message #6 Posted by Namir on 30 Mar 2005, 11:10 a.m.,
in response to message #1 by Klaus

How will you transfer the complied code to the HP33s?

            
Re: breaking the limits of the 33s with a compiler?
Message #7 Posted by VPN on 30 Mar 2005, 11:44 a.m.,
in response to message #6 by Namir

"...and key the output 1 : 1 into the calc"
(-:
[VPN]

                  
Re: breaking the limits of the 33s with a compiler?
Message #8 Posted by Namir on 30 Mar 2005, 12:21 p.m.,
in response to message #7 by VPN

:-<

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

Namir

      
Re: breaking the limits of the 33s with a compiler?
Message #9 Posted by Klaus on 30 Mar 2005, 12:04 p.m.,
in response to message #1 by Klaus

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

      
Re: breaking the limits of the 33s with a compiler?
Message #10 Posted by Eric Smith on 30 Mar 2005, 12:20 p.m.,
in response to message #1 by Klaus

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?

            
Re: breaking the limits of the 33s with a compiler?
Message #11 Posted by Klaus on 30 Mar 2005, 12:42 p.m.,
in response to message #10 by Eric Smith

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

            
Re: breaking the limits of the 33s with a compiler?
Message #12 Posted by Namir on 30 Mar 2005, 2:55 p.m.,
in response to message #10 by Eric Smith

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

                  
Re: breaking the limits of the 33s with a compiler?
Message #13 Posted by Klaus on 30 Mar 2005, 5:02 p.m.,
in response to message #12 by Namir

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.

                        
Re: breaking the limits of the 33s with a compiler?
Message #14 Posted by Alvaro Gerardo Suarez on 31 Mar 2005, 1:38 p.m.,
in response to message #13 by Klaus

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)

      
Sorry but no
Message #15 Posted by Valentin Albillo on 31 Mar 2005, 5:52 a.m.,
in response to message #1 by Klaus

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.

            
Re: Sorry but no
Message #16 Posted by Klaus on 31 Mar 2005, 10:03 a.m.,
in response to message #15 by Valentin Albillo

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

                  
Re: Sorry but no
Message #17 Posted by Namir on 31 Mar 2005, 11:15 a.m.,
in response to message #16 by Klaus

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

[ Return to Index | Top of Index ]

Go back to the main exhibit hall