Extremely naive (and probably stupid) question
| Author |
Message |
|
Jonah Thoma
#1 / 44
|
 Extremely naive (and probably stupid) question
Quote: >I was implementing several standard
>Forth words, and started on 'for'.
>I've been using FPC 3.60 as my comparison platform, so I typed
>: test 5 for i . next ;
>and ran it. I get 17 16 15 14 13 12. So I went to WinForth32 and tried it,
>and 'for' isn't defined. I then went through the entire FPC source tree and
>user contributed library, and couldn't find 'for' used in *any* word.
>Am I missing something *horribly* obvious? Is 'for' a valid word in the ANS
>dialect? Perhaps Tom can tell me if 'for' is known to work or not work in FPC?
>(I looked at the source, and it *seems* OK).
FOR isn't a standard word, and it wasn't in Forth-83 either. I think it's kind of new. There's a good chance that I in FPC does a calculation to get its index, using a couple of return stack items, while FOR just counts down using the top return stack item. You might try
and see whether that works better.
|
| Sun, 05 Aug 2001 03:00:00 GMT |
|
 |
|
Tom Zimme
#2 / 44
|
Extremely naive (and probably stupid) question Quote:
> >I was implementing several standard
> >Forth words, and started on 'for'.
> >I've been using FPC 3.60 as my comparison platform, so I typed
> >: test 5 for i . next ;
> >and ran it. I get 17 16 15 14 13 12. So I went to WinForth32 and tried it,
> >and 'for' isn't defined. I then went through the entire FPC source tree and
> >user contributed library, and couldn't find 'for' used in *any* word.
> >Am I missing something *horribly* obvious? Is 'for' a valid word in the ANS
> >dialect? Perhaps Tom can tell me if 'for' is known to work or not work in FPC?
> >(I looked at the source, and it *seems* OK).
> FOR isn't a standard word, and it wasn't in Forth-83 either. I think it's
> kind of new. There's a good chance that I in FPC does a calculation to get
> its index, using a couple of return stack items, while FOR just counts down
> using the top return stack item. You might try
> and see whether that works better.
Yes, that should work a lot better than using ' i ' ' I ' was never supposed to be used with FOR NEXT, and FOR NEXT isn't in any standard, as far as I know. Tom Zimmer
|
| Sun, 05 Aug 2001 03:00:00 GMT |
|
|
|
Elizabeth D. Rathe
#3 / 44
|
Extremely naive (and probably stupid) question Quote:
>... > As commented by a couple of people in another thread (regarding books), I > pick up Forth for a while, and then drop it. I'd love to use it in embedded > systems, but an 8031 family processor just doesn't quite do it. And a big > problem I keep coming back to in these smaller systems is getting source code > into ROM. > For a lot of what I do, I don't have much money to put into new development
> tools. And I'm still unsure enough of myself in Forth to risk committing it
> for a customer project (I have no qualms about saying I'll do it in 'C').
> Since most of my personal project either involve writing Windows code, or
> 8031 code, I can't put it too much use for a personal projects.
> Years ago I did a complete re-write of C.H.Tings Forth for the 8031. It's
> completely unrecognizable as anything he wrote (it has comments now!), and
> it's a helluva lot faster. But I never did anything with it because of the
> issue of an 8031 being a little too small, but more importantly, getting from
> compiled words to ROM.
> I'd like to hear some thoughts on this, and what people are doing nowadays
> (especially if it can be done "on the cheap"). And if we do talk about this,
> perhaps we should change the thread title.
You might consider our SwiftX line of Forth cross-compilers, designed for embedded applications and supporting the 8031/8051 family (as well as the Atmel AVR, Motorola 68HC11/12/16/68K, and more). It's used by companies such as NASA, FedEx, Boeing, and many more. We programmed a series of 8051-based point-of-sale terminals to a detailed standard also supported by C, and the Forth-based code was consistently half the size of well- optimized C. Our approach is to use the PC (Win95/98/NT) as a host, running not only
a powerful optimizing compiler but also a fully interactive development
environment using an RS232 link to the target. Target support for this
development link takes only a few hundred bytes, and can be discarded
from the final system, which can easily be under 1K and run in on-board
resources (depending, of course, on what it has to do!).
The system is priced comparably with other embedded system programming
tools, but is a good value as it includes not only the development tools
but also a royalty-free multitasking kernel and hundreds of target
routines, all supplied in source form and completely configurable.
For more information, see our web site.
Cheers,
Elizabeth
--
===============================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-372-8493
111 N. Sepulveda Blvd. Fax: +1 310-318-7130
Manhattan Beach, CA 90266
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
===============================================
|
| Sun, 05 Aug 2001 03:00:00 GMT |
|
|
|
Stephen Pel
#4 / 44
|
Extremely naive (and probably stupid) question
Quote: > As commented by a couple of people in another thread (regarding books), I
> pick up Forth for a while, and then drop it. I'd love to use it in
embedded
> systems, but an 8031 family processor just doesn't quite do it. And a
big
> problem I keep coming back to in these smaller systems is getting source
code
> into ROM.
Forth works very well on an 8031, and there are many yachtsmen whose instrument code is written in Forth, as well as access control systems, fire alarms, down-hole tools and so on. MPE's Forth cross compilers give you a choice of a standalone Forth
on the target, or the tiny Umbilical Forth requiring a PC host. The
standalone target has the ROMFORTH extensions which allow your
users to add their own application code in extension ROM or RAM.
--
Stephen Pelc, MicroProcessor Engineering - More real, less time
133 Hill Lane, Shirley, Southampton SO15 5AF, England
web: http://www.mpeltd.demon.co.uk
|
| Mon, 06 Aug 2001 03:00:00 GMT |
|
|
|
Matt Gumble
#5 / 44
|
Extremely naive (and probably stupid) question Quote:
> Years ago I did a complete re-write of C.H.Tings Forth for the 8031. It's
> completely unrecognizable as anything he wrote (it has comments now!), and
> it's a helluva lot faster. But I never did anything with it because of the
> issue of an 8031 being a little too small, but more importantly, getting from
> compiled words to ROM.
> I'd like to hear some thoughts on this, and what people are doing nowadays
> (especially if it can be done "on the cheap"). And if we do talk about this,
> perhaps we should change the thread title.
I'm getting back into it all by attempting to port eForth to Psion Series 3 handhelds, although I'm not entirely sure that the "CS=DS=ES=SS" tiny model will work well on that platform (MMU might kill CS writes..) Has anyone converted (ported is probably the wrong word!) eForth so that
CS is separate to DS=SS=ES?
Cheers,
Matt
|
| Mon, 06 Aug 2001 03:00:00 GMT |
|
|
|
Albert Mitchel
#6 / 44
|
Extremely naive (and probably stupid) question Quote:
> Let me phrase this another way. For an 8031, 16 bit accesses to external > memory are very expensive. It requires a minimum of 4 instructions to load > the B/A pair, and 6 if you want to set DPTR = (DPTR), and I'm assuming that > DPTR already points to were you want to load from, and that you're storing > data in big-endian format. > Contrast this to a 68xx (or just about anything but a PIC) that can do this
> in a single instruction. Dollar for dollar and for clock for clock, it's
> less effective to run Forth on a 8031 than just about anything.
My experience differs. In benchmarking high level Forth running on a 6811 and a 8051 derivative we found only a 7% difference in execution speed, both were running amr's umbilical Forth. If you compare cost then the 8051 will beat a 6811 since 6811's are made of unobtainium unless you are willing to buy increments of 100,000... Quote: > I'm not saying it won't run, don't get me wrong. But my off-hand numbers say
> that a 8mhz 6800 will out-perform a 24mhz 8031. If you don't care about
> wringing performance out of the processor, then sure, take the hit. If your
> entire product line is 8031 based, then it also doesn't make sense to change
> families for a new product.
Actually they run about the same because the 6800 takes four clocks per instruction cycle while the 8051 requires 12. This gives 2MIPS for each. At this point the Forth implementation and optimization is a larger factor. Subroutine threading would give a distinct advantage to the 8051, with direct threading it's a tight race. Quote: > But my entire point really was that anything involving 16 bit operations on an > 8031 is expensive, and Forth is extremely 16 bit oriented. > -- John
16-bit operations are expensive (processor intensive) on an 8-bit machine, true, but that shouldn't come as a surprise to anyone in any language. But when you're dealing with a one-buck controller "expensive" is very relative. -- Albert
-------------------------------------------------
AM Research, Inc. The Embedded Systems Experts
www.amresearch.com (800) 947-8051
-------------------------------------------------
|
| Mon, 06 Aug 2001 03:00:00 GMT |
|
|
|
Tom Zimme
#7 / 44
|
Extremely naive (and probably stupid) question Quote:
> Let me phrase this another way. For an 8031, 16 bit accesses to external > memory are very expensive. It requires a minimum of 4 instructions to load > the B/A pair, and 6 if you want to set DPTR = (DPTR), and I'm assuming that > DPTR already points to were you want to load from, and that you're storing > data in big-endian format. > Contrast this to a 68xx (or just about anything but a PIC) that can do this
> in a single instruction. Dollar for dollar and for clock for clock, it's
> less effective to run Forth on a 8031 than just about anything.
> I'm not saying it won't run, don't get me wrong. But my off-hand numbers say
> that a 8mhz 6800 will out-perform a 24mhz 8031. If you don't care about
> wringing performance out of the processor, then sure, take the hit. If your
> entire product line is 8031 based, then it also doesn't make sense to change
> families for a new product.
> But my entire point really was that anything involving 16 bit operations on an
> 8031 is expensive, and Forth is extremely 16 bit oriented.
> -- John
Well, not necessarily. The code is probably buried now, but when I worked for Samsung, we developed optimizing Forth compilers for 8 and even 4 bit processors that could easily rival hand generated assembly language. These were eight bit forths, where the stack was a byte. The generated code was subroutine threaded and highly optimized. We developed interactive de{*filter*}s for our compilers, so you could debug at the source level. I think the 16 bit mindset for embedded Forths is just a blockade for development
of some "really" competitive compilers. Of course I'm not familiar with other
commercial embedded Forth compilers, I hope they are using 8 bit Forth
implementations for 8 bit processors, because I think you are right, the space
and speed of a 16 bit Forth on an 8 bit processor is not very competitive with an
8 bit 'C' compiler, or hand generated assembly language.
Tom Zimmer
|
| Mon, 06 Aug 2001 03:00:00 GMT |
|
| |
Page 1 of 3
|
[ 44 post ] |
|
Go to page:
[1]
[2] [3] |
|
