GBLONG@NTIVAX.BITNET (03/12/90)
To those who are familiar with C and Forth language, I would like to find out in what situation C outperform Forth and vice versa. A short summary will do, maybe some real life applications where only Forth can do the job efficiently. Thank in advance BLONG -------> gblong@ntivax
koopman@a.gp.cs.cmu.edu (Philip Koopman) (03/17/90)
Here is a non-exhaustive list of some things I have noticed when translating programs from C to Forth (your mileage will vary): 1) Translating C to Forth usually gives you a real mess -- you are best off starting from scratch. Translating from Forth to C usually results in a well-modularized program (assuming you don't have to translate *too* many compile-time Forth tricks). But, Forth->C usually runs slowly because of the awful C overhead for procedure calls. 2) Forth is really good for reducing the overhead for procedure calls, even when you are recursing and need to save state in memory on every cycle to avoid stack overflows. This is mostly because Forth gives you access to the saving mechanism, and C compilers usually must be very conservative since they don't know what you really want to do. 3) Forth is pretty poor at juggling large numbers of stack elements, corresponding to large numbers of local variables. I find that with more than 2 or 3 active stack elements it is often faster and clearer to use local variables, employing a C-like stack frame out in memory. Most of the time, having more than 2-3 active stack elements is a sign of a poorly written Forth program. But, sometimes that is not the case, especially when performing double-precision math or 3-D graphics. Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 2525A Wexford Run Rd. Wexford, PA 15090 Senior Scientist at Harris Semiconductor, adjunct professor at CMU. I don't speak for them, and they don't speak for me.
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/03/90)
Category 2, Topic 14 Message 4 Sun Dec 02, 1990 NMORGENSTERN at 11:45 EST How to determine if a file exists without the overhead of opening it. It calls function 43H which gets the attribute flag using the general-duty DOS call HDOS1. : NonExistent? ( h -- f) \ 0= ok, 2= file not found, 3= path not found >nam 0 swap 17152 \ 4300 hex gets file attribute hdos1 \ atr 0 | code 1 0= if drop 0 then ; \ We don't really want attribute I am looking for a better name for this word. I was all wrong about the Abort Retry etc message. I mistakenly thought that it did not occur when you called file functions directly via int 21H. You can bypass this if you are expert enough. Int 24H returns the address of the Critical Error Handler routine. It is set to the Abort Retry etc routine. I am reminded of the riddle: How do porcupines have sex? Answer: Carefullly However you can test for such problems as door open, etc. by calling INT 25H which is absolute disk read. It attempts to read 1 sector into PAD, and returns an error flag. Drive is 0 for A: 1 for B: etc. Flag is 0 if ok. 2 is drive not ready. See DOS manual for other codes. code DriveError? ( drive -- f) pop ax xor ah, ah mov cx, # 1 xor dx, dx mov bx, # pad int 37 xor ah, ah 1push end-code. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/04/90)
Category 2, Topic 14
Message 5 Mon Dec 03, 1990
NMORGENSTERN at 19:43 EST
The Forth word DriveError? in a previous upload is incorrect. DOS has some
VERY STRANGE effects. I was unaware that Int 37, leaves the flags on the stack
when it returns, and you have to remove them before you return!
DriveError? will test for such problems as door open, etc. by calling INT 25H
which is absolute disk read. It attempts to read 1 sector into PAD, and
returns an error flag. Drive is 0 for A: 1 for B: etc., which is DOS standard.
Return is 0 if ok. 2 is drive not ready. See DOS manual for other codes.
code DriveError? ( drive -- f) pop ax xor ah, ah mov cx, # 1 xor dx, dx mov
bx, # pad int 37 bx pop \ This line added to previous upload xor ah, ah
1push end-code.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/13/90)
Date: 12-08-90 (08:48) Number: 455 of 483 To: NMORGENSTERN Refer#: NONE From: STEVE PALINCSAR Read: NO Subj: FORTH VS C Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) There's a very similar word in HS/Forth called FILE? You give it the address of a string containing the file spec, and it returns a false flag if the file does not exist, or a true flag if it does. The other function is very similar to something I was working on a couple of weeks ago, DRIVE_READY? which uses INT 25 to test a drive by attempting to read sector zero. I got inspired to look into that one by a letter in PC Magazine which described a very strange program that tested drives that way: it included a batch file that created the .COM file by echo'ing ASCII characters into a .COM file (using self-modifying code to get around the unprintability of much of the required code), running the .COM file, and then erasing the .COM file. The effort turned our to be interesting, because as the note in Ray Duncan's Advanced MS-DOS mentions, INT 25 destroys the contents of the registers. I finally found a version of a word in HS/Forth's utility for reading native forth disks that had a version of INTCALL that preserved the registers prior to doing absolute sector reads with INT 25. First time I'd ever even looked at that extension. --- ~ MetroLink: Data Bit NETWork * Alexandria, VA * (703) 719-9648 PCRelay:DCINFO -> #16 MetroLink (tm) International Network 4.10 DC Info Exchange MetroLink International Hub <<<>>> ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
wmb@MITCH.ENG.SUN.COM (02/15/91)
> 1) Most (if not all) 'C' system run a grate deal slower than FORTH. This does not agree with my experience. > Roy Goddard of MPE has coded an application in both Forth and MicroSoft C, > apparently he had to re-write most of the library functions in Assembler > before the C could get anywhere near the speed of the Forth. In general, it depends on the C implementation, the Forth implementation, the processor, the system, the application, the skill of the programmers, and the programmer's "wizardry" level in the respective languages. The whole benchmarking game is fraught with traps for the unwary. Broad comparisons should be taken with a grain of salt. Mitch Bradley, wmb@Eng.Sun.COM
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)
Category 2, Topic 14 Message 24 Wed Feb 27, 1991 ATFURMAN [Alan F.] at 00:23 PST Jack Woehr writes: > I'm sure glad that most of our competitors use C; it guarantees > that we underbid them every time. Right on! Never argue with a fool--work your way into a position where you can eat his lunch... :-) ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp