Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!rutgers!att!cbnewsl!bobp From: bobp@cbnewsl.ATT.COM (robert.phillips) Newsgroups: comp.sys.handhelds Subject: Re: What If - someone wrote a HP-48SX C compiler? Message-ID: <4686@cbnewsl.ATT.COM> Date: 21 Mar 90 12:54:28 GMT References: <21580037@hpcvra.CV.HP.COM> Reply-To: bobp@cbnewsl.ATT.COM (robert.phillips,sf,) Distribution: na Organization: AT&T Bell Laboratories Lines: 58 In article <21580037@hpcvra.CV.HP.COM> frankw@hpcvra.CV.HP.COM (Frank Wales) writes: >There are certain fundamental difficulties: > > -- the 48 has no file system, so any implementation of > open(), close(), read(), write(), etc. would need heavy > rework, never mind stdio; > -- no processes, so no fork(), exec(), etc.; > -- signal(), setjmp(), and many other commonly used > system calls would need work to behave reasonably -- > some might be impossible to make work; > -- 99% of the 48's maths functionality has no parallel in C; > -- fundamental types would be non-standard by most common > C implementations -- the 48 CPU has 64-bit registers > and 20-bit nibble-based memory addressing, for example, which > pushes the usual portability limits; > -- the 48 operating system is written in a language (RPL) which is > like a sort-of polymorphic, sort-of object-oriented, stack-based > blend of Forth, LISP and other stuff, and has few things in common > with C, certainly at the User level (no pointers, no memory > allocation, no reasonable analogues to goto, break or continue). > I think the C compiler idea is pretty bogus, but I think you may be missing the boat about C. Open(), close(), etc. are not part of the C language-- they are UNIX system calls that implementations of C on other operating systems find convenient to provide in some form. A C language implementation can work perfectly well without open(),close(),read(),write(),fork(),exec(), signal(),setjmp(),etc. The Amazing Dan wants C, not UNIX. To be strictly correct, C provides no math capabilities beyond the usual +,-,/,%,*, and bitwise operations. There is a standard math library, but one can always create a non-standard math library. I think your winning objections may be paraphrased as, "The HP 48sx is not a computer (IN THE C LANGUAGE SENSE). > However, if your >final goal is to bring existing C code to the 48, or to turn the machine >into a C one instead of an RPL one, I feel that you would ultimately be >frustrated by the obstacles which the design of the HP-48 presents. >-- >Frank Wales, Guest of HP Corvallis, [frank@zen.co.uk||frankw@hpcvdq.cv.hp.com] >Zengrange Ltd., Greenfield Road., LEEDS, England, LS9 8DB. (+1)-503-750-3086 I agree. I think one of the reasons Frank mentions all the UNIX system calls is to apply the argument of portability. Indeed, one of the chief advantages of C is its portability, and this advantage would be sacrificed by any reasonable implementation on the HP (non-portable custom math library to call built-in functions, non-standard i/o, etc.). It WOULD be an exercise for anyone with too much time on his/her hands, but it is not as if compilers have never before been ported to oddball architectures. HP usually does a pretty good job on their "language" design. In all probability, the compiler you write would not approach the speed and efficiency of HP's language. Rob Phillips AT&BL 190 River Rd. Summit, NJ 07901 201-522-6359 attunix!bobp