a684@mindlink.UUCP (Nick Janow) (12/10/90)
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: > That metacompiler could be written in Forth, and by running it on top of C > Forth 83, it would run on anything that anybodys likely to want to use as a development platform. (And C Forth 83 is cheap). How slow would that be, compared to a FORTH compiler written for any particular processor?
wmb@MITCH.ENG.SUN.COM (12/11/90)
> I am happier with the idea of bringing up a Forth quickly by using your C > Forth 83 approach than I am with the MASM approach. ... > I have been under the impression that to put Forth on a new machine using > your C approach requires that one have a C compiler available on that > machine. Am I in error on this point? If the C compiler is required it > would still seem to leave a place for something like eforth on various > systems. C Forth is a good way to go to get Forth running on a full-blown system based on some J. Random processor. Most new full-blown systems these days tend to run Unix, and tend to come with a C compiler. But that's not what I was talking about in the discussion about MASM and eForth. I was suggesting that, rather than using MASM as a "poor man's cross compiler" (thus limiting the development platform to a PC, making life hard for everybody, and making Bill Gates even richer), it would be better to use a metacompiler. That metacompiler could be written in Forth, and by running it on top of C Forth 83, it would run on anything that anybody is likely to want to use as a development platform. (And C Forth 83 is cheap). MASM is a wretched cross-development tool, as Dr. Haskell found out. It doesn't handle byte order, alignment, or loader format problems. You end up having to write a clumsy program in some other external language (e.g. F83 or C or whatever) in order to patch around those problems. With a metacompiler, you can factor out access procedures to handle the aforementioned problems. You could even implement those procedures to *generate assembler source code* if you wanted. For example, the "putbyte" procedure could easily output a text line line like ".DB 12" or whatever. Metacompilers can be relatively simple; the F83 metacompiler is a good example. Since eForth uses CATCH/THROW, you wouldn't even have to solve the limited forward reference problem. Mitch Bradley, wmb@Eng.Sun.COM
wmb@MITCH.ENG.SUN.COM (12/12/90)
> How slow would [C Forth 83] be, compared to a FORTH compiler written > for any particular processor? It depends on the machine architecture (i.e. how good it is at running C and Forth), the quality of the C compiler, and the implementation technique used for the native Forth under comparison. Clearly, a machine like an RTX-2000, which is optimized for Forth but which is only a so-so C machine, will give you a different answer than a SPARC, which is a good architecture for C but only so-so for Forth. On SPARC, C Forth 83 runs about 50% slower than my direct-threaded native SPARC Forth (i.e. the time ratio is 3:2), using the Sun optimizing C compiler at high optimization levels. This is probably close to the best case. On 68010, the time ratio is about 2:1, comparing the same things as for SPARC (i.e. C Forth 83 compiled by Sun's optimizing C compiler compared to my direct-threaded native 680x0 Forth). On a PC, it is probably worse, but it depends strongly on the particular C compiler. The speed differences between C Forth 83 compiled under several different PC C compilers are quite noticeable. It also depends strongly on whether it is compiled for 16 bit stacks or 32 bit stacks. For the purpose that was being discussed (metacompiling eForth), I doubt that speed differences of this order of magnitude matter very much. Mitch Bradley, wmb@Eng.Sun.COM
bouma@cs.purdue.EDU (William J. Bouma) (12/13/90)
In article <9012121624.AA00871@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: >> How slow would [C Forth 83] be, compared to a FORTH compiler written >> for any particular processor? > >On SPARC, C Forth 83 runs about 50% slower than my direct-threaded >native SPARC Forth (i.e. the time ratio is 3:2), using the Sun optimizing >C compiler at high optimization levels. This is probably close to >the best case. Given any decent compiler, the difference comes down to an indexed- indirect jump plus a jump for the C 'switch' as opposed to an indirect jump for the direct-thread. I too have found the ratio in speed to be under 1:2 on several different processors. If you compile the C-switch code into assembler instead of machine code and then spend about 30 seconds on it in an editor, you can direct thread it. The switch statement already builds a table of all the code addresses so it can do the indexed jump. My plan is to write sed scripts for various architectures that will do that optimization. -- Bill <bouma@cs.purdue.edu>
shri@ncst.ernet.in (H.Shrikumar) (12/18/90)
In article <9012121624.AA00871@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: >> How slow would [C Forth 83] be, compared to a FORTH compiler written >> for any particular processor? > >On SPARC, C Forth 83 runs about 50% slower than my direct-threaded >native SPARC Forth (i.e. the time ratio is 3:2), using the Sun optimizing ...and ... >On 68010, the time ratio is about 2:1, comparing the same things as for I understand the configurations are in each case ... C-coded FORTH *over* a UNIX or similar OS *over* raw hardware. versus native direct-threaded FORTH *over* raw hardware. The System overheads, even if you are the only job, will matter for small sized fast benchmarks. Mitch, could you clarify please ? >For the purpose that was being discussed (metacompiling eForth), I doubt >that speed differences of this order of magnitude matter very much. True enough. Also, this small loss of speed is the price you pay for writing over a multi-user system which some one could use to say login and work while you are doing something else in FORTH. Thats the idea behind C-coded FORTHs running on UNIXes. >Mitch Bradley, wmb@Eng.Sun.COM -- shrikumar ( shri@ncst.in )