home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / hp48 / 7243 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  2.9 KB
  1. Path: sparky!uunet!spool.mu.edu!sgiblab!cs.uoregon.edu!news.uoregon.edu!nntp.uoregon.edu!stevev
  2. From: stevev@miser.uoregon.edu (Steve VanDevender)
  3. Newsgroups: comp.sys.hp48
  4. Subject: Re: C compiler for HP48
  5. Date: 21 Jan 93 10:54:29
  6. Organization: University of Oregon Chemistry Stores
  7. Lines: 48
  8. Message-ID: <STEVEV.93Jan21105429@miser.uoregon.edu>
  9. References: <C15xss.1H6@nvcc.uucp> <books.196.0@fsunuc.physics.fsu.edu>
  10.     <1jmjcfINN1cb@emmental.csv.warwick.ac.uk>
  11. NNTP-Posting-Host: miser.uoregon.edu
  12. In-reply-to: phudl@csv.warwick.ac.uk's message of 21 Jan 1993 16:35:27 -0000
  13.  
  14. In article <1jmjcfINN1cb@emmental.csv.warwick.ac.uk>
  15. phudl@csv.warwick.ac.uk (Mr S J Liddicott) writes:
  16.  
  17.    One advantage of the 48 is that its ROM routines would be the 
  18.    C library/kernal, so code needn't be that big.
  19.  
  20. Every so often, someone thinks of the idea of writing a C
  21. compiler for the HP 48.  I think it's not worth the effort, for
  22. several reasons.
  23.  
  24. The Saturn is not a processor that would be easy to write a code
  25. generator for.  Register usage is non-orthogonal.  There are lots
  26. of register fields, few of which correspond well to traditional C
  27. data types.  The hardware stack is limited to 8 20-bit values, so
  28. a parameter-passing stack would have to be implemented in
  29. software.  As a consequence, it would be difficult for a C
  30. compiler to generate efficient Saturn code, and typical C
  31. programs wouldn't be easily portable to the Saturn architecture.
  32.  
  33. The ROMs don't have that many routines that correspond to
  34. standard C library routines.  You'd still have to write a C
  35. runtime library, a task complicated by the need for an HP 48 C
  36. system to interface with the normal RPL environment.
  37.  
  38. Perhaps the biggest problem with any C development environment
  39. for the HP 48 is that it would be at odds with the fundamentally
  40. interactive nature of the HP 48.  C is a reasonably good language
  41. for developing larger applications, but it is also difficult,
  42. arcane, and not designed for interactive, incremental program
  43. development.  C has its place, but not on the HP 48.  System RPL
  44. is by necessity the systems programming language of the HP 48,
  45. and Saturn assembler the language of choice for the low-level and
  46. time-critical applications.  You could write a C-like compiler
  47. for the HP 48, but I do't think you could really implement ANSI C
  48. well on its architecture.
  49.  
  50. Just because a machine can be programmed in assembly language
  51. doesn't mean that it can or should have a C compiler.  C is not
  52. the be-all and end-all of programming languages, and any serious
  53. programmer should be able to work in a variety of languages.
  54.  
  55. It would be cool to see a Scheme interpreter/compiler for the
  56. HP 48, though. :-)
  57. --
  58. Steve VanDevender     stevev@greylady.uoregon.edu
  59. "Bipedalism--an unrecognized disease affecting over 99% of the population.
  60. Symptoms include lack of traffic sense, slow rate of travel, and the
  61. classic, easily recognized behavior known as walking."
  62.