caeaves@icaen.uiowa.edu (Cory A Eaves) (06/24/91)
I have looked all over for a C compiler for my new HP48SX, and I have drawn the conclusion one doesn't exist. Does anyone know of one? If not, why not? Doesn't seem like that bad of an idea. One could take the C source for an existing compiler and modify it without a whole lot of effort to target the Saturn. Imagine the software this would open up for us? How about it? Anyone interested helping with this project? I have exper- ience with compilers but not a lot with the HP. Any HP gurus interested? -- ceaves@pps2-po.phyp.uiowa.edu (Just call me Cory)
bson@rice-chex.ai.mit.edu (Jan Brittenson) (06/24/91)
In a posting of [24 Jun 91 02:14:52 GMT] caeaves@icaen.uiowa.edu (Cory A Eaves) writes: > How about it? Anyone interested helping with this project? I have > experience with compilers but not a lot with the HP. Any HP gurus > interested? I looked at GCC, and quickly gave up on this. It seemed impossible to create a machine description for the Saturn. The biggest obstacle problem is that the Saturn screws up register allocation - the registers don't interact orthogonally. A, B, and C often interact freely with each other, while D often only interacts with C. See ADD, for instance. Registers R0-R4 are used for storage only; no arithmetic available. Only registers A and C interact with memory, via D0 or D1. The interaction patterns also vary from instruction to instruction. There are bit operators, but only for the low 16 bits. 8 levels of hardware stack, although a stack could be emulated using D0 or D1. Which leaves only one register. Things get messy real quickly. Adapting GCC to the Saturn is an order of magnitude more difficult than adapting it to the 8086! But then I don't know much about GCC. It may be doable. On the other hand, I'm sure there are compilers that are easier to adapt (with a substantial recoding effort), but GCC is attractive since you only need to do it *once*, in the back-end descriptions and then reuse it with F77, Pascal, whatever, front-ends. And GCC is free. There is a way out: have GCC produce code for a highly orthogonal, target machine. Something like a 64-bit PDP-11 with 20-bit addressing and variable-size instructions (varying by the nybble). Then use an interpreter on the HP-48 to implement this machine and run the code. Sort of like the p-code idea, except we're talking about a register machine of course. Say a machine with 256 64-bit registers, or other architectural features that studiously allows the compiler to fully explore its optimizing potential. Sure, you lose a lot in the interpretation, but will regain some (to be taken literally) by the improved optimization. Finally, according to RMS, GCC *is* capable of producing a pseudo-code intended primarily for C interpreters. I'm not sure how well suited it is for implementation on the HP-48. Besides, brain-storming wild CPU designs is half the fun! :-) -- Jan Brittenson bson@ai.mit.edu
apm279l@vaxc.cc.monash.edu.au (06/24/91)
In article <NVxHUKy.677729692@l_eld07.icaen.uiowa.edu>, caeaves@icaen.uiowa.edu (Cory A Eaves) writes: > > I have looked all over for a C compiler for my new HP48SX, and I have drawn the > conclusion one doesn't exist. > > Does anyone know of one? If not, why not? Doesn't seem like that bad of an > idea. One could take the C source for an existing compiler and modify it > without a whole lot of effort to target the Saturn. > > Imagine the software this would open up for us? > > How about it? Anyone interested helping with this project? I have exper- > ience with compilers but not a lot with the HP. Any HP gurus interested? > > > -- > ceaves@pps2-po.phyp.uiowa.edu (Just call me Cory) I'm actually working on it. I've been writing a (crudish) C compiler for a "generalised" machine (ie a C front end compiler which produces assembly-style instructions for which you write a machine-dependent back-end. Mainly to see if I can do it! Well it's about 1/2 way there. Very little optimisation yet too. I was going to make Saturn my first back end. I guess it'll end up as approximately ansi-C. Will let the net know... Peter PS: I have a brother in law in physics at uiowa - do you know jsa@.. ?
hoford@gynko.circ.upenn.edu (John Hoford) (06/24/91)
In article <1991Jun24.210635.86948@vaxc.cc.monash.edu.au> apm279l@vaxc.cc.monash.edu.au writes: >In article <NVxHUKy.677729692@l_eld07.icaen.uiowa.edu>, caeaves@icaen.uiowa.edu (Cory A Eaves) writes: >> >> I have looked all over for a C compiler for my new HP48SX, and I have drawn the >> conclusion one doesn't exist. >>... .... >I guess it'll end up as approximately ansi-C. Will let the net know... > >Peter > A C like compiler for the 48 would be very useful, but I think I would be better if the language was adapted to the 48's system for example: main() should be called with the stack as the arguments. the data structures for all types in the 48 should be defined the major operators should be overloaded to operate on them many of the builtin calls of the 48 should be defined You should be able to access ore create 48's variables I think c++ is a much better language to suport the functions needed On the other hand a very simple c like language would be useful one which: had no float worked only with the machine code defined data types (.w .s .a) had the ability to call 48 system calls (or the ability to build a lib of such calls) had malloc and free this tould be much simpler to write and debug and would allow and be mostly a replacment for assembly programming but a standard lib could be built with it that provided the functionality that is neded One thing that has prevented me from trying to build a compiled language for the machine is my lack of understanding of asm convensions within the 48 for example: how should malloc and free be impleted how should autmatic variables be created where should a function call put its return value John D. Hoford
veit@du9ds3.uni-duisburg.de (Holger Veit) (06/25/91)
In <45094@netnews.upenn.edu> hoford@gynko.circ.upenn.edu (John Hoford) writes: >In article <1991Jun24.210635.86948@vaxc.cc.monash.edu.au> apm279l@vaxc.cc.monash.edu.au writes: >>In article <NVxHUKy.677729692@l_eld07.icaen.uiowa.edu>, caeaves@icaen.uiowa.edu (Cory A Eaves) writes: >>> >>> I have looked all over for a C compiler for my new HP48SX, and I have drawn the >>> conclusion one doesn't exist. >>>... I wonder whether the first idea which one to use was the "monster" GCC. Only because it's free? It it obvious that this one is at least two categories to large. But what about the "small-c" compiler. This one is also PD, lacks of course some constructs, e.g. floats, but is sufficient for standard purposes (if you however want to port the MACH Kernel to the hp48, you probably cannot avoid some rewriting :-). Small-C was a long time ago ported to the Z80 for CP/M, a reasonable library exists, a "portable" assembler is there, and there is also a version for 8086. This may be a base for crafting a hp48 c-compiler. Small-C was/is (?) available from simtel20 and elsewhere. Holger -- | | / Holger Veit | INTERNET: veit@du9ds3.uni-duisburg.de |__| / University of Duisburg | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO | | / Fac. of Electr. Eng. | UUCP: ...!uunet!unido!unidui!hl351ge | |/ Dept. f. Dataprocessing |
ochealth@unixg.ubc.ca (Occupational Health Ochealth Safety) (06/25/91)
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
bson@rice-chex.ai.mit.edu (Jan Brittenson) (06/26/91)
In a posting of [25 Jun 91 06:45:45 GMT] veit@du9ds3.uni-duisburg.de (Holger Veit) writes: > I wonder whether the first idea which one to use was the "monster" > GCC. Only because it's free? No, because it generates small and fast code. > But what about the "small-c" compiler. The compiler may be small, but the code is at least 8 times larger and correspondingly slower, than what GCC would generate. Small-C appeared in Dr. Dobb's (where I originally typed it in from for 8080/Z80) with the explicit statement that it was intended to be read, not used. -- Jan Brittenson bson@ai.mit.edu
jurjen@cwi.nl (Jurjen NE Bos) (06/26/91)
ochealth@unixg.ubc.ca (Occupational Health Ochealth Safety) writes: [About a C compiler] >Thought for the day: wouldn't a FORTH compiler be a little easier to implement? What?! The HP48 has the most sophisticated Forth compiler ever written. If you mean compiling (whatever the language) to machine code, you'll need a bunch of library routines that eat up RAM. The actual code is a bunch of calls to the routines. If you do this, why not use internal RPL? The ROM is you library, programs are extremely small, you can mix in machine code whenever you like, it is very fast (only three instructions per routine!), and hopefully, HP will support us in the near future (hopefully).
akcs.vttoth@hpcvbbs.UUCP (Viktor T. Toth) (06/30/91)
Lines: 2 Implementing a C compiler, even with floats, isn't the real problem. Implementing a reasonably complete function library *IS*.