mnelson@vmsa.oac.uci.edu (03/21/90)
There has been some talk recently about the desire to have a C compiler (running on a PC or 48sx) which can generate 48sx binaries. It seems to me that this is overkill. C has lots of features (especially file i/o etc.) that would appear to be inapropriate for the 48sx. I had similar cross-compiler thoughts a while ago, but the language in my dreams was HP's very own RPL (the stuff *on* the 48sx). When I pick up my 28s (no, I dont have a 48sx yet :-( ) I *think* rpl; thoughts of FORTRAN (the vogue language for us high energy physicists) never enter my mind. It seems to me that there are two advantages in trying to make an rpl compiler over a C compiler: 1) the users of such a package wouldn't be required to learn C in order to reap the benefits (especially since they already know rpl), and 2) it seems to me that it would be easier to implement a complete rpl compiler; most likely a C compiler would wind up being a sub- set of the language, which would probably p.o. the purists. So there sits my $0.02. Given the choice between an rpl or C developement system for the 48sx, I would actually prefer rpl. Other opinions? +--------------------------------------------------------------------------+ Matt Nelson, Physics Dept., University of California, Irvine, CA 92717 (714)856-6496 internet: nelson@psroot.ps.uci.edu bitnet: mnelson@uci +--------------------------------------------------------------------------+
grue@batserver.cs.uq.oz.au (Frobozz) (03/21/90)
mnelson@vmsa.oac.uci.edu writes: > There has been some talk recently about the desire to have a >C compiler (running on a PC or 48sx) which can generate 48sx binaries. >It seems to me that this is overkill. C has lots of features (especially >file i/o etc.) that would appear to be inapropriate for the 48sx. I had >similar cross-compiler thoughts a while ago, but the language in my >dreams was HP's very own RPL (the stuff *on* the 48sx). I agree with C being overkill, and I also like RPL a lot. > It seems to me that there are two advantages in trying to make >an rpl compiler over a C compiler: 1) the users of such a package wouldn't >be required to learn C in order to reap the benefits (especially since they >already know rpl), and 2) it seems to me that it would be easier to implement >a complete rpl compiler; most likely a C compiler would wind up being a sub- >set of the language, which would probably p.o. the purists. > So there sits my $0.02. Given the choice between an rpl or C >developement system for the 48sx, I would actually prefer rpl. > Other opinions? I don't think that an RPL compilier would perform much better than the machine does at present. The only performance win I can see are removing the overhead of transfer from one object to the next (3 instructions) and optimizing away some of the stack operations (this is likely to be quite difficult to do, since it is going to be useful/necessary to use a lot of code from the machine's ROM). It should, however, be possible to improve the performance of loops or conditional statements. (I'm not sure how they are stored internally but they seem awfully slooooow). Compiling RPL would seem to be like compiling forth, not really worth the improvement in performance. Extensive optimization will improve the performance but optimization is difficult, slow and hard to get really correct. Turning now to C compiliers for the HP-28: (don't have a 48 since they are not in Australia yet) I also considered porting one of the standard compliers for C, I ran into a nasty problem with the size of a byte, on the Saturn processor it would be nice to use the 4 bit nibble as the basic unit of address, 2 nibbles as a character, 5 as a pointer and some other number as an integer (maybe keep 5 here too). The compiliers that I looked at seemed to like the idea of the basic unit of address being an 8-bit byte. Porting a C compilier would not be impossible, it would be quite difficult (i.e. it would take more time than I am currently willing to invest). I intend to look a little more deeply into this one when I get time. [ As an aside, is there anyone who understands the GNU-C machine descriptions? It is likely to take ages to figure out what to do, especially for something as wierd as the Saturn. ] I haven't even looked into the problems involved with handling floating point numbers/arrays/lists and so on. Do you keep the format of arrays the same?? Do you support the wonderful data types on the 28?? Arguments to the main program can be grabbed off the stack, this isn't quite like C's argc, argv but in the setting it would seem quite nice. I do believe that a simple compilier could be written quite quickly for the Saturn. If little or no optimizations were performed the task would become a lot easier. I have written some really simple compiliers (in BASIC yukky) for an old 8080 based machine, they didn't optimize very well but the resulting programs ran heaps faster than BASIC did (the only other choice was assembler which I don't like very much). I would be willing (and am quite interested) in writing such a simple compilier for the Saturn, I am waiting until I get a HP-48 before I start (I don't like memory losts :-) If somebody comes up with a decent assembler (just has to support the basics -- no need for macros or conditional assembling. Just labels and op-code would be adequate), writing such a compilier would be quite easy. (do it in RPL???) Any other comments? Pauli seeya SNIF Paul Dale | Internet/CSnet: grue@batserver.cs.uq.oz.au Dept of Computer Science| Bitnet: grue%batserver.cs.uq.oz.au@uunet.uu.net Uni of Qld | JANET: grue%batserver.cs.uq.oz.au@uk.ac.ukc Australia, 4067 | EAN: grue@batserver.cs.uq.oz | UUCP: uunet!munnari!batserver.cs.uq.oz!grue f4e7g4Qh4++ | JUNET: grue@batserver.cs.uq.oz.au --
alonzo@microsoft.UUCP (Alonzo GARIEPY) (03/27/90)
In article <3001@moondance.cs.uq.oz.au> grue@batserver.cs.uq.oz.au writes: > > I don't think that an RPL compilier would perform much better than the machine > does at present. The only performance win I can see are removing the overhead > of transfer from one object to the next (3 instructions) and optimizing away > some of the stack operations. I don't have any statistics to give you, but consider for a moment how much error checking code there is in the HP48. Also consider how many functions work on multiple object types (+ has 25 variations). All kinds of error and type checking can be eliminated with a compiler. I wouldn't be surprised to find that that RPL is twice as fast for programs with a great number of simple instructions. Alonzo checki