Re: hardware errors, do C and Forth need different things in hardware?
- From: John Passaniti <nntp@xxxxxxxxxxxxxxxxx>
- Date: Mon, 22 May 2006 02:52:32 GMT
Jeff Fox wrote:
The questions were all like this, "Does the follow Forth code
do what the comment says or it is a bug that *always* needs fixing
in *every* possible case, maybe even needing hardware traps?"
Given that criteria, *none* of the examples you posted are categorically *always* considered errors to a C programmer, since I can easily show at least one case (usually taken from my past and current experience) where they are not considered errors. So your entire argument fails right there. You're making grandiose claims about C programmers and "C think" and here I am providing a counterexample.
Again, you talk about Forth in an embedded systems context, but when you talk about C, you refuse to do the same. You compare apples to oranges, which of course is nothing new to you. You've been delighting comp.lang.forth with your fruit-salad nonsense for years.
BEGIN AGAIN \ forever
If
that means 'forever' or until power is cycled or reset is pressed
and that *could* be valid code
then it should *NOT* be catagorically considered a bug
and it should *NOT* be disallowed either by the compiler
or by the hardware.
It isn't disallowed by C. Any functioning C compiler will generate code that does exactly what it says. The equivalent C code is either:
while (1)
;
Or...
do {
} while (1);
Format as you like, the compiler doesn't care.
Okay, dispensing with the question of C, let's move next to the hardware. Code this in a C compiler for any of the microprocessors I typically use (Z80-family, 6502-family, 8051, HC08, ColdFire, ARM, and probably others), and they will gladly allow that code to run until the end of time or the next power cycle, which ever comes first.
So if it isn't disallowed by C, and isn't disallowed by the hardware... what exactly is your point again?
If
it is simply a bug in *all* cases
then the software or hardware should prevent it
or fix it.
There are two cases to consider:
Your code is clearly a bug in *some* cases, but since C (like Forth) can't tell if this is a bug or the actual intent of the programmer, C will faithfully compile the code to do what the programmer wants-- just like Forth. C puts absolutely no barrier to the programmer here and does what the programmer wrote. And since we're talking about embedded systems here and not general purpose computing, we typically don't have any operating system on the target that could possibly complain either.
So we turn to hardware. Here again, the code may certainly be a bug in *some* cases, but the microprocessor can't know that. So on smaller microprocessors, the decision is to simply ignore the issue-- processors like the Z80-family, 6502-family, 8051-family, and many others typically don't have any kind of watchdog in the system at all. If the specific application calls for a watchdog (for example safety-critical systems), it is added externally and thus becomes a decision by the system designer. In processors that that have integrated watchdogs, I have yet to see any microprocessor or microcontroller where the programmer couldn't disable it if they knew it wasn't necessary.
As far as I got you got the answers right whenever
you left the questions in the orginal context.
You didn't provide the context for each example, except possibly in your own head. I wish you would be honest about that, but for some reason you feel the need to lie. You wrote a message that was intentionally ambiguous and vague so that you could make another one of your grandiose points that went nowhere when held up to the light of day.
It must be a Zen thing-- I guess you're always trying to find balance. For every worthwhile insight you provide comp.lang.forth, you feel the need to balance it with bullshit straw-men arguments that don't make any sense. But don't worry Jeff, I'm sure you can issue more speeches in front of audiences who won't question you. Must do wonders for your ego.
.
- References:
- Prev by Date: Re: hardware errors, do C and Forth need different things in hardware?
- Next by Date: Re: Sea of Processors
- Previous by thread: Re: hardware errors, do C and Forth need different things in hardware?
- Next by thread: Re: hardware errors, do C and Forth need different things in hardware?
- Index(es):
Relevant Pages
|
