Re: hardware errors, do C and Forth need different things in hardware?
- From: jmdrake_98@xxxxxxxxx
- Date: 23 May 2006 13:55:06 -0700
Jeff Fox wrote:
This thread is about whether these traditional embedded
Forth sorts of things that I described earliker are easily
mistaken for bugs in C view or might look like they might
need or want the sort of complications that this code avoids.
1. begin again \ forever
Every Forth programmer is suppose to be able to read that.
It is simple. There is no confusion about what it says.
It does not specify an error condition and to consider it an
error would be introduce a real error. I would expect that
most programmers in traditional Forth have done it many
times.
I agree. Not an error. It's an endless loop that's obviously
documented as an endless loop by the "\ forever". A bug
is when someone accidently creates an endless loop.
For example someone forgetting to increment a list
pointer.
2. begin ?key until \ no key pressed
Another non-error. Misinterpretting it as an error that needs
hidden background tasks or watchdog timers or interrupts
is sort of the opposite of this simple straightforward code
that does what it says, says what it does and is the
sort of thing that gives Forth an advantage.
Hmmm...ok. I'd call this a "documentation quirk".
The code is clear. Keep looping until a key is
pressed. Why didn't the comment just say that?
begin ?key until \ wait until key pressed
Anyway, if the keyboard is unplugged at this point that's
a hardware error. ;) Of course, assuming hotplugging
the keyboard is ok, it's easily fixable.
3. begin 255 p@ 8 and until \ port bit always false
Just like 2, except waiting on an event that might or might
not be a key press. But it does what it says and says
what it does, ad it is clear and simple.
Another commenting quirk (to me anyway). The code is
clear. The comment isn't. Why would you expect
the port bit to ALWAYS be false if there's a chance there
might be an event when it's TRUE? I'd rather see:
begin 255 p@ 8 and until \ port bit false unless event X
Maybe "event X" is critical temperature of nuclear reactor
reached. Maybe the code after this loop is "initiate
emergency shutdown".
4. data rom-address !
Traditional embedded style Forth has always made this sort
of thing easy. Maybe on this project when I wrote to ROM it
gets decoded as io output. Maybe the comment will read,
"turn on the panel light" and it won't be an error at all
either in software or hardware. Writing to ROM could be
something to give us an advantage over hardware or
software that make the real problem harder to solve.
If it confuses solutions for bugs it will introduce REAL bugs.
The first computers I programmed on used memory
mapped I/O. (TRS-80 model 4 and color computer).
"Peeking" and "Poking" ROM was legal. Admittedly
this was beyond much of what I was doing at the time.
5. : demo 2 0 / ;
demo
It is unlikely to define demo that way, but division by zero is
'undefined.' So we get to do what we want since we got to
define what / does with 0. And since that is what our code
says we want to do here, we assume that the action that
we want to have associated with division by zero will take
place and that no error is going to happen here.
Throwing an error that we didn't want would be a bug.
Ok. I honestly never thought of that. But I think that's
dependent on:
A) defining your own CPU or
B) redefining "/" as a word rather than a primative
I tested # 5 on Pentium ColorForth (the version I have
anyway) and it locks up. I suppose I could redefine
the "/" to check and see if the divisor is 0 and take
some action other than executing the Pentium
division primative. But wouldn't that slow my code
down? Still I suppose this doesn't apply if your
talking about Forth running on a Forth chip. And
I'm guessing you're giving us another "hint" about
the new Intellasys chips. ;)
Consider that you want to write the shortest, fastest and
lower power consuming code that you can to do xyz.
We have been talking about that goal. And after you write
the inner loop of your app you realize that it has a balanced
stack, exactly the same number of DUPs as DROPs. So
you ask yourself, in this embedded Forth what will happen
if I remove the final DROP in the loop?
Ok. That's pretty cool. I had to read it a few times to
understand.
9. a program pops from a stack more items than it pushed
to the stack.
These non-bugs are getting more powerful. The ability to
keep taking the same items off the stack again and again
without generating an error is something that can be
exploited. Since stacks are faster than memory here
and can deliver a repeating pattern faster than reading
it from memory or dealing with hardware stack underflow
trapping it is another win. It is another form of freedom
to beat hardware and software that has to work the
way mainframes work.
Also interesting.
And people are suppose to figure out the pattern of the quiz
by now. Nine non-bugs each getting more useful and a
more important example of what distinguishes where
traditional cooperative Forth has gone in the last twenty
years and things that give it an advantage are suppose to
suggest that the biggest non-error is the last.
10. hardware that will go to sleep when reading ports and
waiting for a neighbor to write is in a sleep state
and neighbors are also a sleep trying to read.
If any of the others were confused for errors it is likely
that this one would be too. This characterized everything
we are doing. If you confuse it with an error you will have
trouble understanding what we do and what advantages
we get by doing it the way we do it. Since it is a bit of a
trick question because we haven't released all the
hardware and software details of what we are doing I
gave everyone more than nine hints.
Ok. Here's how I see this might work. One or more
of the sleeping processors is waiting for a signal
external to the chip? For example a digital audio
signal comes in and causes a cascade of chips
waking up in sequence?
Regards,
John M. Drake
.
- References:
- Prev by Date: Re: Another way to do x^n
- Next by Date: Re: Is Forth really easy or is it complex?
- Previous by thread: Re: hardware errors, do C and Forth need different things in hardware?
- Next by thread: EuroForth 2006 Call for Papers
- Index(es):
Relevant Pages
|
|
