How to develop a random number generation device

Disagreeing with you on a design point is hardly "miffed." And, not being a chicken, I don't have feathers.

Adding a circuit to find and fix a presumably impossible state is worthy of "kluge" if anything is. Your circuit brought up the interesting and, I think, important question of whether we should incorporate such catcher/fixer things into our hardware and software. Pardon me for caring about ideas like that.

Technical blunder? In a newsgroup? A technical blunder is a mistake that fries thirty NMR probes, or blows up jet engines, or makes us recall a hundred instruments. Newsgroups don't matter.

John

Content-Transfer-Encoding: 8Bit

John Lark>The reliability of a good digital system should be dominated by

Certainly none caused by the hardware itself, and things like ESD and EMI can be shielded against, but what about the occasional cosmic ray flipping a bit?

From _Soft Errors in Electronic Memory ? A White Paper_ [

"Even using a relatively conservative error rate (500 FIT/Mbit), a system with 1 GByte of RAM can expect an error every two weeks; a hypothetical Terabyte system would experience a soft error every few minutes."

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

John

If you're using deep sub-micron technology, like modern dram, whose soft errors compromise reliability, then something like ECC becomes mandatory. What scares me is stuff I can't do anything about, like FPGA config ram.

Things like using redundant data storage, with background checks and checksums, can be done, but that seems like more trouble than the device density is worth.

John

On Sep 9, 1:48 pm, John Larkin wrote: [....]

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.

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.

Nested curly brackets are just as dangerous, or moreso.

John

I have many customers. Sometimes I conferr with them as regards product performance or interface; I almost never discuss internal design issues with them. Few of them ever see schematics or source code.

John

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.

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.

As are the declares of any soft of array.

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.

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

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

What in the world are you talking about?

Oh. I don't like circuits that do accidental things.

None at all. The issue is a serious one.

You might want to work on the "fearless" part.

Sometimes it's interesting, and I don't watch TV.

No. But I might be looking for people.

John

Multiple exit points are no problem - you can easily

return;

from a function wherever you like.

Multiple entry points to a *function* are a bit more awkward - but you can enter other types of block at multiple points. If you know C you might enjoy this:

They have, of course - not many people use C to write applications for desktop machines any more. They use C#, java, all sorts of other languages and frameworks that do most or all of what you are asking.

However, to take up your analogy, todays microcontroller *is* similar in power to a PDP-11, so C is now in fact quite a good fit!

Im not just thinking of the indexes of state machines and I'm certainly not defending code that has this sort of problem. I am pointing out is that this is an area where people must be careful. Just coding without GOTOs is no insurance against any problem that GOTOless code is supposed to prevent.

There are lots of limitations you accept when you code in C.

This is hard to do in C:

IntRoutine:

Ooops heres the rest of what I was saying:

On Sep 10, 8:12 am, John Larkin wrote: [....]

In C it is hard to do things like this:

AnotherReti: RETI

Interrupt0: ... stuff ... CALL AnotherReti

; Code runs as non-interrupt code ... stuff ... RET

This is handy because it lets you deal with a process that may take longer than the shortest time between interrupts. You have to keep track of how many interrupt pulses there have been and react correctly but it isn't too tough.

I also write a lot of multi entry routines that look a little like this:

DoSomethingWith17: MOV A,#17 DoSomething: ; Process the number in A ... stuff ... RET

I put the comment: ;******* Fall Through *********************************** in to make it really obvious what I'm doing.

They did partly. It is called Pascal. Specifically the Borland flavor of Pascal. Pascal has run time checking and very strict type checking. This helps a lot to prevent the common "type related" errors such as losing the signedness of a number.

Pascal generally doesn't allow you to express anything that requires mixing of code and data spaces.

In the OO version of Borland Pascal, they check an object's VMT for being likely to be valid before they dispatch a virtual function.

This seems to be a good start. The places where it falls short is in working with floating point values. In ordinals, you can specify the valid range that the number can be. For floats you can't. Also since the exponent of the float can change, there can be problems with lost bits.

I think it would be better if the accuracy and range was stated and the compiler made the choice about the right type (float, double, or extended) to be used.

I think it was Godel that proved that no compiler could out smart a stupid programmer, but at least it could check for the obvious stuff.

On Sep 10, 10:55 am, John Devereux wrote: [....]

I disagree. Many programs today are written using MFC which ensures that it is a hopeless morass of bugs.

Good thing i kept my backup HD as well as my OithRink subscription. Copper.net plainly "offers" newsgroups, but more plainly DOES NOT support them.

It is *NOT* possible to calculate a random number sequence; any such foolish attempt will result in a (perhaps long) repeating sequence. Even a "short" (say 1-10%) sample of a loooong sequence will fail one test of a truly random sequence of the same length. If you want random, start with (or re-seed from) a table of random numbers, similar to what was used by the military ages ago. Or..take a tested random process (eg: nuclear decay, brownian motion), digitize that for either random values or a "lookup table". Oh...you were asking about one of those tests? Any given value can and will repeat - - - randomly!

Well yes (although that's C++, not C). And in fairness to Microsoft, they have been trying to phase out MFC for the last 5 years. I was making the point that people *have* been working on desktop development systems designed to fix exactly the problems John Larkin was complaining about.