Newsgroups: comp.sys.handhelds
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!van-bc!ubc-cs!unixg.ubc.ca!ochealth
From: ochealth@unixg.ubc.ca (Occupational Health Ochealth Safety)
Subject: Re: C Compiler for HP48SX
Message-ID: <1991Jun25.165720.2139@unixg.ubc.ca>
Sender: news@unixg.ubc.ca (Usenet News Maintenance)
Nntp-Posting-Host: chilko.ucs.ubc.ca
Organization: University of British Columbia, Vancouver, B.C., Canada
Date: Tue, 25 Jun 1991 16:57:20 GMT

A C compiler shouldn't be impossible, and if the 48 had a disk system, it 
could RUN on the 48 (old CP/M had 64K or less and had Turbo Pascal).

BUT, that is not really the point of this article.

I find rpn easy enough to use in most cases, but I find it extremely tedious
to translate non-rpn code into rpn, especially when trying to optimize the code.
Keeping track of the stack can get pretty ugly!

Thought for the day: wouldn't a FORTH compiler be a little easier to implement?
ANd instead of a C compiler, how about a C translator. That way, existing RPL
source code could be compiled to run quickly (RPL types wouldn't have to learn
C) and piles of C/Pascal style code wouldn't have to be tediously re-coded.
(Even most pseudo-code can get funny when translating into rpl. you could use
lots of local variables, but those aren't very efficient)

Unfortunately, this might be twice as much work. 

Any thoughts on this?

John Paul Morrison

