Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bu.edu!wang!harvee!esj From: esj@harvee.UUCP (Eric S Johansson) Newsgroups: comp.lang.forth Subject: Re: Eric's funny for the day Message-ID: <4321651@harvee.UUCP> Date: 17 Feb 91 14:15:52 GMT References: <9102141832.AA19990@ucbvax.Berkeley.EDU> Organization: gators 'r us Lines: 95 X-Version: Rodney's UUCP modules 05/09/90 V1.15 I'm glad I made you smile. (it's a wonderful day in the neighborhood...) [the following has been edited a bit - esj] In article <9102141832.AA19990@ucbvax.Berkeley.EDU> RAYBRO%HOLON@UTRCGW.UTC.COM > > Ha, ha, ha! This is exactly what J-forth and (in a slightly clunkier > fashion, IMHO) Multi-forth do on the Amiga. There's only a few objections > I'd have to `standardizing' that: > > Can you get TurboC to use libraries compiled for use with MicroSoftC > on the PC? Can you get C libraries at reasonable cost for the 68hc11? > (I know right off of two compilers that run in the $1000 range!) The issue of different binary formats and library formats is a sticky one that gives compiler venders another reason to use Tums. The PC world is a messy place whereas in the unix world we only have a half dozen binary formats (count as of last week). I guess the only answer I have for you is state that which binary/library format used is a vendor specific issue. suppliers of libraries usually support the top X popular binary formats so if you had a forth that linked to C libraries, you probably could find a vendor that supported the library format you needed. Object/library format is one of my selection criteria when I choose a compiler and library suppliers no matter what language I work in. C libs for small machines at "reasonable cost" ( example: 6811 ) I could claim that routines you find in an ANSI C RTL you would not be able use in a micro-controller environment like the 6811 but you would be justified in calling that a arguable point. Since you claim that you know of two suppliers of 1000$ C compilers, I suggest one could look there for a library supply. BTW, I consider 1000$ reasonable (if not cheap) for a compiler when a company is buying it. The only beter deal I know of are the FSF compilers for unix systems. They are less buggy than most commerical C/C++ compilers and better supported. (argue this point with me in email :-) > Also, if you actually roll-your-own C library interface, you > have to know how the compiler it is intended for keeps its stuff > on the stack, which I believe is implementation dependant, and not > specified in the ANSI standard. That you must have a stack, that's > standard. How you keep things there (in what order) is up to > you and your machine. > The issue of calling sequences is strongly tied to object format. A compiler that produces object files in the same format as another compiler but uses a different calling sequence will tend to not have a very large market place. > > Also, once you have a whole set of libraries, you have to have a way > to add to them or modify routines: this is what forth is all about. I tend to view libraries as a fixed set of atomic objects. I can't change them (except for bug fixes), or add to them. Changing the behaviour or adding routines is not acceptable IFF the library is defined by a standard. On the other hand, changing or adding to my local libraries is ok because no-one outside of my work group is counting on them. ( I will rant about resuable code at another time.) > If I don't like emit, or want it to emit somewhere's else... I can > change it. hmmm. *i* just redirect stdout if i want the equivelent of redirecting emit. :-) :-) > With C libraries, you need the source (no real decompiler > possible), you need a librarian, and you need to be able to compile > into the library...Why not use C in the first place? Well... Using C instead of forth *is* the option picked by most managers of software projects. > [NOTE: this is not a flame. [TINF?] Understood and not taken as a flame. > The idea is OK for practice where > the operating system (and its implementation) make a c-like interface > and library access desirable, but I don't think it belongs as a foundation > of the standard. These sorts of things become non-portable real quickly... I sort-of dissagree. I believe an inter-language interface belongs in the standard of any language. I also believe that the INTERFACE can be made portable whereas the implementation will tend to not be portable. > > raybro --- eric -- ... ^^^ eric johansson UUCP ...!uunet!wang!harvee!esj esj@harvee.uucp * * a juggling fool AT&T (617) 577-4068 (w) o HAM ka1eec \_/ CSNET johansson%hydra@polaroid.com or hydra!johansson@polaroid.com source of the public's fear of the unknown since 1956