HP Forums

Seen on Comp.sys.hp48: http://hpgcc.sourceforge.net

"HP-GCC is a suite of programs that allow you to program ARM-based HP calculators in C. Being released under the GPL, it is free to use and modify. HP-GCC is a project aiming to make advanced programming in C easy."

"We are proud to announce the first public Beta of HP-GCC. This version is meant for Windows PC's without Cygwin installed. There are still many things to do but this release has a lot of features. It includes a greyscale library, SD card access, several examples programs (including Tetris and Chess games) and many other cool things. Being the first release it's likely to be full of bugs though. Download it Here - the .zip file contains everything you need."

"Why should you program in C?

Ease of use. SysRPL is only found on HP calculators, and it is not trivial to master. Being stack based, it is very different from most languages. C is in industry standard, with only a few HP specific things to learn. Experienced programmers can apply their knowledge without the burden of learning a whole new programming language.

Speed. The most commonly used language for advanced programming is 'System RPL', or 'SysRPL'. On modern calculators, SysRPL is mostly executed by an emulated 'Saturn' processor. C on the other hand is executed directly by the ARM chip. The same program written in C will be many (up to 100) times faster then the equivalent SysRPL program.

Power. There are many things that can be controlled via a C program, but not by a SysRPL program. For instance, a C program could alter the CPU speed, display flicker-less greyscale, or control the beeper precisely. A pure sysRPL program could not."

However, once you learned SysRPL,

you'll see that it's a powerful language,

and it has advantages to understand how

the RPL OS works, especially if you want to

write system compliant applications.

Just try to emulate a Parameterized Outer Loop in C;-)

An other advantage of USR-RPL and SysRPL is that you can actually write program on the calc.
I will however give a try to hpgcc once I have time

Arnaud

Quote:

---

Just try to emulate a Parameterized Outer Loop in C;-)

---

Can you give me an example of exactly what this is? I have never used the SysRPL

Chris W

Hee hee; forgive me, but even RPL, the little that I've used on the 48G models, are still somewhat FORTRAN like! I mean if it weren't for FORTRAN, I'd be totally lost as to RPL!

Hi Chris,

I'll try to explain in a more general manner.

Almost everything in the HP-48 which you can interact with

is realized in the form of a Parameterized Outer Loop (POL).

When you turn on the machine, normally the first thing

you'll see is the stack, which is a special POL.

When you enter numbers into a command line,

you're inside a POL.

On the G(X) you have an input form engine,

which is also based on a POL.

A POL is a framework for system compliant applications.

It defines standard mechanisms for user interface handling,

like keyboard input, display, and data output.

A POL also includes a level of error trapping,

event handling (alarms, turn off,...), power management, and more.

This is important on feature-loaded machines like the HP-48.

Otherwise, every simple application would have to manage

system events on it's own.

To learn more about POLs and system RPL programming
please refer

to RPLMAN.DOC and some tutorials on www.hpcalc.org .

HTH

Raymond

Edited: 29 Oct 2004, 2:34 a.m.

Is that a port of TIGCC or something completely different?

Ciao.....Mike

A good FORTRAN programmer may do FORTRAN in any language.

Ciao.....Mike

BTW, I did an HP-41 emulator in FORTRAN (alas only useful on IBM mainframes).

A C program will run 100 times faster for about 10 clocks after which it will bog down because it has hogged all the memory and left none for the vairables.

Remember "Hello World"? Compiled to about 10 KB.

I did not find anyhting difficult about learning RPL.

"A C program will run 100 times faster for about 10 clocks after which it will bog down because it has hogged all the memory and left none for the vairables."

Huh? Can you please explain your reasoning?

.

Sounds like an ordinary event loop to me. There is no built in language construct in C to specifically do that, but there's no reason it can't be done in C. In fact many applications written in C do just that.

Chris W

Not Getting the gifts you want? The Wish Zone Can help.

Quote:

---

Huh? Can you please explain your reasoning?

---

I doubt he can. Sounds like he knows little about C, and probably has an unjustified bias.

Chris W

Not Getting the gifts you want? The Can help.

Hi,

I didn't say that it's impossible to build a POL in C,

but it doesn't make sense on Saturn-based

(even when emulated) machines, because it's built-in.

It's one of the fundamental user interface mechanics

in RPL machines, which to understand and use is

mandatory for any programmer of serious interactive

applications for the HP-48/49.

Exceptions may be some real-time games,

which define their own limited event handling.

However, IMHO the first thing in this area is to learn SysRPL,

to get an idea of the capabilities of the RPL system,

before reinventing the wheel;-)

Raymond

RPL was originally designed for a calculator where memory was at a premium and speed was not. When an RPL program is compiled the excutable code will be much smaller than the source code. This because the excutable commands will be in the form of pointers that point to the routine in PROM.

C, on the other hand, compiles into an executable code that is generally larger than the source code. One of the reasons for this is that the compiler imports libraries of routines most of which may or may not be used.

It came as rather a shock to me in the begining days of my first C class to see a program intended to display "Hello World" on the screen compile into more than 10 Kbytes of executable code. I realize this is an extreme example of the ratio of executable code to source code, but the principle holds, a C program will use a lot more memory than an RPL program. If you have memory to burn this is no big deal, but in a calculator you do not have memory to burn.

Hmm, one could say that the 49g+ has lots of memory...

However, I'm a friend of memory-efficient programming,

so RPL and assembly language are my favourites on RPL machines.

Maybe someone should try to write a program like SpeedMiner

(available on hpcalc.org for the HP-48 and 49g)

in C...it won't have a much faster feel,

but occupy multiples of memory of the original SpeedMiner,

and will be likely to consume more battery power.

Raymond

(replying to Raymond and 'unspellable' at once)

Hi,

(regarding size of C programs vs RPL)

"This because the excutable commands will be in the form of pointers that point to the routine in PROM."

Yes, using built in routines makes the final binary smaller. At present, C programs have to contain most of the library calls within the binary. There are some simple OS calls which are in the ROM that don't consume space, but these are not terribly helpful for the average program.

"It came as rather a shock to me in the begining days of my first C class to see a program intended to display "Hello World" on the screen compile into more than 10 Kbytes of executable code."

I hope you remembered to turn on optimizations. Even so, alot of that is unused bloat. The executable format has alot of slack. Considering the average cluster size on hard drives these days, there is no difference between a 1 byte and a 1kb file. They consume the same amount of hard drive space.

"Hello World" with HPGCC takes less then 1kb. 1kb is still huge for "hello world". Why is it so big?

Basically it has to run in a vacume. The binary must set up the MMU, allocate itself memory, and do many other tasks that really should be handled by an OS. I'm guessing this accounts for half of the 1kb. Also, as you mentioned, there is no runtime library to use. All functions currently have to be provided in the binary.

There are 2 ways to fix this though: Firstly, it is entirely possible to just have one copy of the runtime in memory, as a library. This should cut down code bloat considerably.

Secondly, the binaries are currently compiled as true ARM instructions. With a little tweaking they could be compiled for Thumb mode. This should reduce the size by about 30-40 percent on average.

" If you have memory to burn this is no big deal, but in a calculator you do not have memory to burn."

Considering you can have hundreds of megabytes on an SD card, I'd say there is memory to burn. Even without an SD card, you have 450kb of RAM and 600kb or flash ROM to use.

"Maybe someone should try to write a program like SpeedMiner
(available on hpcalc.org for the HP-48 and 49g)
in C...it won't have a much faster feel,
but occupy multiples of memory of the original SpeedMiner,

I'm sure a C speedminer would be perhaps 5 times the size of the asm version. I also bet it would be much quicker to write :-)

"and will be likely to consume more battery power.""

Why would it use more battery power? If anything, it would use far less. With an emulated Saturn program, the CPU runs at 75MHz - you can't control it. 75MHz is extreme overkill for a simple game.

Using a C program, you have the power to adjust the clock. You could easily underclock to 12MHz or less. This should save battery power.

best,

Al

Hi,

regarding the power:

This could be true.

On a real HP-48, the program performs a CPU shutdown after each game step,

providing the lowest possible power consumption.

Only the display and keyboard lines are active at this point.

This may be problematic on the emulated CPU in the 49g+,

except if they have put some more brains behind the Saturn

shutdown mechanics emulation.

Regarding the time to write SpeedMiner in C:

Yes, maybe someone can do it quick'n'dirty,

but that was not the objective for writing the program.

I wrote it especially to demonstrate efficient resource

usage on an HP-48 (and 49g).

I don't remember how long it actually took to finish the program

it was the thrill to make it possible,

and it didn't take that long.

I don't know if you know the program,

it's only about 1KB in size, and has all bells and whistles.

A considerable amount of development time was used to introduce

a new and ultra-fast pseudo-random number generator

to place the mines. I limited the mines to 200,

but not because of speed.

The 'mine-thrower', as I called the generator,

is able to generate more than 400 random numbers in an eye glimpse,

and an important point is that it uses absolutley no RAM.

To make it short, I think C and ARM assembly have their uses

where you aren't able to solve a problem withRPL/ML

but many tasks can be efficiently done in RPL/Saturn assembly.

However, since I don't use my 49g+ because it has quality problems

like an unreliable keyboard, and user interface drawbacks like

the uncomfortable keyboard layout (for me),

because the ENTER key isn't where it's on my HP-48,

I don't care too much for the 49g+ ;-)

Regards,

Raymond

Forth, Inc. has loads of stories from their experience where for example it was estimated that a team of C programmers would need two years to complete a certain job, but it was finally decided that it would be done in Forth, and one man did it by himself in six months, reducing the hardware requirements in the process. They commonly find that projects can be completed in one-tenth the man-months that would have been needed in C.

I don't speak RPL, but I understand it is very Forth-like. I see C as a very inefficient language with serious limitations, but it's amazing what company politics and marketing can do.

Hi,

If you like Forth, there is no reason why someone couldn't write a Forth interpreter in arm code (either assembly or C). The problem with the current sysRPL implementation is that it is an interpreted language running under an emulator. Hence it is much, much slower then it could be.

This isn't an issue for simple mathematical programs of course. Things like numerical integration would benefit from being rewritten, as would more advanced games (think Doom on a calculator!). And because native code is much faster, you can afford to underclock the CPU to save battery power.

Personally I prefer languages like C or Basic to Forth/RPL, but thats just subjective opinion.

cheers,

Al

The HP-41 sold me on reverse-polish notation. Until I started using it for data acquisition and control, I could have gone either way (algebraic or RPN); but RPN suddenly proved to be much better for the data acquisition and control, where the HP-41 was interfaced to several instruments at once (as was later the HP-71).

The HP-71 got me into Forth. What a polarization though! When you include the HPIL, Math, and Forth/assembler modules as well as scores of LEX files from the user groups, that BASIC was by far the best I've seen. In constrast, the HP-71's Forth was very poorly done-- kind of slopped together with apparently little serious thought. It sounds like you're saying they did a rather poor job of the current sysRPL too, at least by neglecting to optimize its critical parts in the HP-48's native assembly language.

In going to Forth, I was glad to be rid of most of the syntax rules and punctuation. That part mostly does fall under the heading of "subjective opinion" as you say. Reverse-polish vs. algebraic is also partly a matter of how the individual thinks. But for my own uses (which may not be typical), one of C's limitations is that its compiler is not part of the user-accessible system, so the language itself is not fully extensible like Forth is. BTW, about the "Forth interpreter" comment-- There are various types of threading in Forth, but they are all compiled. Interpretation does not occur during normal program execution.

Paul wrote,
> a C program could alter the CPU speed, display flicker-less greyscale, or control the beeper precisely. A pure sysRPL program could not."

Flicker-less grayscale capability would depend on the LCD's controller. Is the 48's LCD controller separate from the processor? Controlling the beeper and altering the clock speed could be done in any language that gives full access to the hardware, if the hardware design allows it. Does the possibility exist with HP-48 for users to write the equivalent of the 71's LEX (Language EXtension) files in assembly, not only to speed up critical processes, but also to get direct control of the hardware?

Hi,

I think you are confusing the HP48 with the HP49g+. The HP48 is based on the Saturn processor. All the ROM is written in sysRPL and Saturn asm and executes nativly. The HP49G is basically a HP48 but with enhanced software. It still runs a Saturn processor, at 4MHz.

The 49g+ has an ARM processor at 75MHz (which is much faster then a Saturn clock-for-clock), however it mainly runs a saturn emulator. This emulator executes the old HP49g ROM. This ROM has been patched so critical operations are in native ARM code, but most things are still emulated.

"Flicker-less grayscale capability would depend on the LCD's controller. Is the 48's LCD controller separate from the processor?"

Again, you mean the HP49g+, NOT hp48. On the 49g+ everything is built into a single chip - including a LCD controller with _hardware_ greyscale.

"Controlling the beeper and altering the clock speed could be done in any language that gives full access to the hardware, if the hardware design allows it."

Of course. My point is that sysRPL is currently emulated, and does not offer easy access to hardware. A new language needed to ported to allow this hardware access and admittedly C is much more popular in industry then Forth.

cheers,

Al