Re: a dozen cpu's on a chip

MooseFET wrote:

On May 13, 12:04 am, Martin Brown <|||newspam...@xxxxxxxxxxxxxxxxxx>
wrote:

MooseFET wrote:

On May 12, 8:12 am, John Larkin
<jjlar...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
[....]

show off how tricky they can be. Something without pointers. Something
that is impossible to crash.

No nontrivial language can ever be proven to be imposible to crash.

Minimalist languages like Modula2 have been proved to be formally
correct


I would like to see this proof. I seriously doubt that there isn't an
error in it like the one pointed out by Godel in set theory. It may
also not be a proof at all. Many so called proofs are just arguments
that a proof could be done and not actual proofs. To be a proof all
the steps must be shown.




and compilers that implement the formal specification exist.

The static testing possible with that strict Pascal like grammar catches
a very large proportion of common programming errors at (pre) compile
time. It is still possible to write something that will crash, but you
have to try a lot harder to do it.


I write a lot in Pascal. Although the strict type checking and more
obvious syntax does prevent 90% of mistakes, it still leaves the 10%.
Run time checking prevents some conditions from continuing to do
damage but the program still bombs.

If you include hung systems in crashed ones, the problem becomes much
harder (even though it started out as imposible).


Ada's high integrity subset for safety critical work is another one.


Did you know that there was a mistake in the spec for ADA that allowed
"correct" compilers to produce two different results from the same
source code. I have the details around here somewhere. It was
something very nonobvious about what type an expression had. It takes
some pages of coding to make the problem show.

I assume that the subset was made after this was discovered.


The
full Ada implementation is too much like a race horse designed by
committee with way too many bells and whistles hitching a ride.


ADA is 3 of everyones favorite languages.


I suspect LISP comes pretty close to being impossible to crash, but when
you include practical implementations some of the OS impurities will
provide ample opportunity to bring the thing to its knees.


Since LISP isn't compiled it is a lot harder to imagine it killing a
system its self but the base interpreter can't be written in LISP so
the error would be there.


For my money any routine that attempts to read from uninitiallised
memory, or write to memory it doesn't own should be terminated with a
page fault there and then (unless the location has been pre-defined as
memory mapped I/O).


Ownership should be strictly enforced for this to work. On the
various X86 machines the hardware does exist that could allow the OS
to lock things down. It would make the call process a lot slower but
in critical systems it may be worth it.

I think that hardware designers could do a lot to improve matters.
Having a call-return stack, a parameter stack, return value area, and
local variables area all independant and enforced in hardware would
make it much harder to mess things up.

When a pass by reference is done, the reference could contain the
permissions and size information so that the called routine would be
restricted to only writing where the callee wants it to.



Regards,
Martin Brown
** Posted fromhttp://www.teranews.com**


The business of having programs in the same address space as data would seem to be asking for trouble.
Two independent memories, one exclusively for program and another exclusively for data would help; adding (programmable) protected areas for stacks and other program areas would also be of help.
But, at the end of the day, the damnOS must be written to USE those protections, and in a logical, intelligent manner.
And the M$ gooies fail in that regard...
.

Relevant Pages

  • Re: XP sometimes balks on boot-up
    ... to catch this trap. ... Memory corruption, other hardware ... The most common cause of this is hardware memory corruption. ... A kernel stack overflow. ...
    (microsoft.public.windowsxp.general)
  • Re: Time to fix my PC
    ... intermittently bad) is the power supply 'system'. ... Intermittent memory often passes all tests at room temperature. ... Responsible computer manufacturers provide comprehensive hardware ... such as the crash code or data from system logs in the OS ...
    (comp.os.linux.hardware)
  • Re: Time to fix my PC
    ... Intermittent memory often passes all tests at room temperature. ... such as the crash code or data from system logs in the OS ... only certain hardware can crash a properly designed ... I'll pull out the audio and DVD drives while testing to simplify ...
    (comp.os.linux.hardware)
  • Re: Overview Of New Intel Core i7(Nehalem) Processor
    ... The memory can be logically divided into sections and security can be ... good, however, it requires that the hardware prevent the application ... return addresses all on the same stack. ... the parameter stack doesn't have to contain the return addresses. ...
    (sci.electronics.design)
  • Re: Good Microsoft TV ad!
    ... I've noticed that on DEC hardware, programs weren't crashing due to the extensive memory ... How is an error occuring in memory causing a program crash not of any concern? ... Typical for NOC-monkeys not to know about this sort of stuff. ... I haven't had to physically touch computer hardware for my job in years. ...
    (comp.sys.mac.advocacy)