Re: How to develop a random number generation device

On Mon, 10 Sep 2007 07:28:23 -0700, MooseFET <kensmith@xxxxxxxxx>
wrote:

On Sep 9, 7:35 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Sun, 09 Sep 2007 16:21:24 -0700, MooseFET <kensm...@xxxxxxxxx>
wrote:

On Sep 9, 1:48 pm, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
[....]
Watch dogs don't always recover the system from a glitch. If you are
storing data in battery back RAM or flash, you need to be sure that
wrong values don't cause things to hang in some non-recoverable way.

One of my programming rules is that data should never be able to crash
code.

The assignment statement is more dangerous than a GOTO.

Assignments don't crash in assembly, since assembly is untyped. The
only math error possible is a divide-by-zero trap, or a stupid
pointer. What's important is that program flow doesn't bomb just
because some cal table is trashed.

I think you missed the point. What I mean is that an assignment can
change all of the future operation of the program so it can (if you
don't code carefully) lead to hang up states and the like.

Well, that's bad code. The point of coding in state machines, or at
least thinking in them, is that all possible cases are accounted for.




There's nothing wrong with GOTO; hell, Dijkstra didn't even have
regular access to a computer, and didn't actually program much. I
think in state machines, so GOTO is perfectly logical. In assembly, a
conditional branch, or a computed/table driven jump, are the primary
control structures.

I certainly agree. Quite a lot of my coding contains GOTOs in the
form of jump instructions. When you write on an 8051 you often do
things like this:

SqrtFastOut:
RET

Sqrt:
MOV A,Work1
ORL A,Work1+1
ORL A,Work1+2
ORL A,Work1+3
JZ SqrtFastOut

Zero is a special case that my sqrt routine would get wrong otherwise.

C doesn't encourage subroutines that have multiple entry and multiple
exit points. Pity.



Nested curly brackets are just as dangerous, or moreso.

As are the declares of any soft of array.


I's occurred to me, more than once, that C was invented to run on a
PDP-11, and that a $400 Dell has 10,000 times the memory and a
thousand times the speed of an 11. So why doesn't somebody invent a
language (and a methodology) that produces/forces reliable code and
requires less debugging, and does rudimentary stuff like data and code
separation, at some expense in runtime resources?

John

.