ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/28/90)
Date: 02-26-90 (10:45) Number: 2967 (Echo) To: DAVID ALBERT Refer#: 2907 From: PETE KOZIAR Read: NO Subj: INNER INTERPRETER Status: PUBLIC MESSAGE The best reason for the inner interpreter on the 80x86 family is because there's only really one stack, pointed to by SP. It makes sense to use the fastest access for the most-used stack, namely, the parameter stack. Another reason is that a lot of the 80x86 FORTHS have their roots in 8080 FORTHS for which the CPU was more primitive. One disadvantage of subroutine-threading is that it uses an extra byte or two for the instruction prefix. --- * Via Qwikmail 2.01 The Baltimore Sun ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/28/90)
Date: 02-26-90 (10:45) Number: 1760 (Echo) To: MIKE SPERL Refer#: 1756 From: PETE KOZIAR Read: NO Subj: 386 ADDRESSING Status: PUBLIC MESSAGE The 80386 modes that allow access to all of memory will cause problems when used with DOS, DESQview or Windows. Just be aware that it can be done, but the problems go beyond the assembly language part of it. --- * Via Qwikmail 2.01 The Baltimore Sun ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/01/90)
Category 3, Topic 7 Message 29 Tue Feb 27, 1990 D.RUFFER [Dennis] at 23:30 EST Re: PETE KOZIAR > The best reason for the inner interpreter on the 80x86 family is > because there's only really one stack, pointed to by S. It makes > sense to use the fastest access for the most-used stack, namely, > the parameter stack. Has anyone done some real anaysis on this? With every high level definition pushing something onto the return stack when it starts and popping it back off when it is done, it seems as if the return stack is used more than the parameter stack. I've heard this argument for years. I'm just curious if it has been substantiated with fact. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/01/90)
In article <571.UUL1.3#5129@willett.UUCP> ForthNet@willett.UUCP (ForthNet articles from GEnie) writes: > The 80386 modes that allow access to all of memory will cause problems > when used with DOS, DESQview or Windows. Just be aware that it can be > done, but the problems go beyond the assembly language part of it. If the 80386 protected mode program is run using a DOS emulator such as Phar Lap DOS EXTENDER, then you have no problems running under DOS, DESQview or Windows/286 (but you can't run under Windows/386). Laboratory Microsystems UR/Forth 386 uses the Phar Lap product, which yields a 32 bit Forth with the performance of the equivalent 16 bit Forth, plus the luxury of a flat address space (and virtual memory, too -- you can't run out of dictionary space as long as you have sufficient free disk space!) I have used the Phar Lap product on several applications (a Smalltalk-80 interpreter, XLISP, and two versions of the SPICE simulation program) with excellent results. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
toma@tekgvs.LABS.TEK.COM (Tom Almy) (03/01/90)
In article <584.UUL1.3#5129@willett.UUCP> ForthNet@willett.UUCP (ForthNet articles from GEnie) writes: >Category 3, Topic 7 >Message 29 Tue Feb 27, 1990 >D.RUFFER [Dennis] at 23:30 EST > >Re: PETE KOZIAR > > > The best reason for the inner interpreter on the 80x86 family is > > because there's only really one stack, pointed to by S. It makes > > sense to use the fastest access for the most-used stack, namely, > > the parameter stack. > >Has anyone done some real anaysis on this? With every high level definition >pushing something onto the return stack when it starts and popping it back off >when it is done, it seems as if the return stack is used more than the >parameter stack. Well I did, some years ago. Until the 80386, all of the Intel processors did best with direct threaded code. With the 80386 it appears to be a wash. (Note that with the 68000 and 6502 processors, subroutine threading is a decided win because the 68000 has multiple stacks and the 6502 has difficulty with threaded code). The parameter stack is used more than the return stack because most words executed are primitive code words, and they do not use the return stack. With subroutine threaded code, the primitives are reached by calls which puts the return address at the top of the machine stack. This virtually necessitiates that the return stack be the machine stack. The BP register then has to be used as the parameter stack pointer, and push/pop operations are performed by swapping BP and SP before and after the stack references. You can still win with subroutine threaded code in all these processors by realizing that its not threaded code at all! If the compiler is smart enough to generate inline code for the more common primitive operations (rather than CALLs) that a very significant performance gain is achieved. The memory constraints on 8080s especially and 8086 real mode to a lesser degree tends to make this memory hogging approach impractical, but it makes a great deal of sense for 80386 processors running in protected mode with lots of memory. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/07/90)
Date: 03-05-90 (09:14) Number: 1775 (Echo)
To: MIKE SPERL Refer#: 1772
From: PETE KOZIAR Read: NO
Subj: PROTECTED MODE 386 Status: PUBLIC MESSAGE
Well, I'm going to have to think a little more on this, but here's some
stuff off the top of my head about the linear address mode of the 386:
1. The 386 memory management is designed around a minicomputer model,
using the idea of "priviliges." There is an "operating system" that
can do some special things (like change memory maps), and an
"application program" that is restricted. If there is already an
operating system loaded (like DESQview or Windows), it takes the role
of the operating system, so a lot of the operating-system-like
functions are not allowed, or will be allowed only through special
operating-system calls when real 80386 Opsys's finally arrive
(Windows/386 really isn't a 32-bit opsys, OS/2 386 isn't out yet,
and DESQview forces the 386 into the "multiple-8086" mode).
2. DOS and the BIOS assume 8086 emulation mode, so every time you want
to call DOS or BIOS, you must return the machine to its "boot-up"
configuration. This can cause real headaches if the data you want to
send to the opsys is in a piece of memory that disappears when you
restore to the 8086 map. You could probably double-buffer the data,
but it wouldn't be pretty.
3. There are apparently "DOS-extenders" around that give you the linear
address space. I have never used one, and have no idea how they work.
I haven't crossed this bridge just yet. I have an application
where it would really be nice to be able to use some of the features of
a real opsys (like shared regions), but I can get around it for now.
By the way, the Laxon/Perry F83 was a lot more readable than F-PC.
L&P had some comments in the shadow screens; it doesn't look like any
of the shadow-comments made their way across into F-PC.
I think the first step on the way to a real 386 FORTH would be to
use the instructions that are available even in the 8086 emulation
mode. It would certainly speed up double-precision, and the extra
segmentation registers might make some things (like @L) a bit easier.
Here's today's trivial speed-up. Three of the most-used constants
are certainly -1, 0 and 1. F83 defined them as CODE words, but F-PC
does not. Their definitions are easy, and left as an exercise to the
reader.
---
* Via Qwikmail 2.01 The Baltimore Sun
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/08/90)
Category 3, Topic 7 Message 31 Tue Mar 06, 1990 D.RUFFER [Dennis] at 22:20 EST Re: PETE KOZIAR > Here's today's trivial speed-up. Three of the most-used consants > are certainly -1, 0 and 1. F83 defined them as CODE words, but > F-PC does not. A warning is in order here. polyFORTH defined 0 and 1 as constants for years. Recently, however, we implemented a way to revector the number conversion and interpetation process. Under this system, it is occasionally neccessary for 0 and 1 to pass through the number conversion process. Then, defining numbers as constants can get you into a lot of trouble. We have now resorted to removing their heads in the nucleus. This allows us the speed advantage in the nucleus, but eliminates the interpretation problems on the application side. I don't know if this would be a problem in F-PC, or if compiling headless code is a feature of F-PC's meta compiler. I only note that making constants for frequently used numbers is not always desireable. FYI DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/09/90)
Category 18, Topic 61
Message 4 Thu Mar 08, 1990
D.RUFFER [Dennis] at 00:48 EST
Re: ritchie@hpldola.HP.COM (Dave Ritchie)
> Are there any forths available for the 80C196 processor?
I haven't found anything in our libraries Dave. However, Forth, Inc. sells a
version of their chipFORTH that targets to the Intel 80C196 Evaluation Board.
An IBM PC is used as the host system, but the target application can be
completely stand alone. It also doesn't take much to convert the nucleus to
support other development boards. Give them a call for more information at
(213) 372-8493 or to have them send you some sales literature.
FYI DaR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'