Mars Rover Controlled By Java

[Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=]

In embedded software, we frequently write to memory addresses that are

in turn mapped to hardware control registers. Early optimizer design
was frequently done by software folk not familiar with this practices,
often optimizing out writes to address that they didn't see being
later read.

...which is the correct thing to do, IMO. If you want such dead stores or
loads to happen in any case, you need to tell the compiler the changed
semantics of that value in any case. In fact, on a modern processor, even
if the compiler did not optimize the memory operation away, it is quite
likely it wouldn't happen at all or in time.

Crippling the optimizer is the wrong solution to this problem.

Jan

 

[Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=]

d) There is no reason to believe a real time system cannot be virtual

machine based. It is technicaly feasible and all the benefits of seperating
code from hardware/OS are just as relevant on embedded systems as they are
on desktops. Just look at cell phones.

Or, indeed, some smart cards (for instance, from GEMplus or axalto).

Their advantage is that you need to certify the JVM only once as to its
sandbox guarantees, and can then put new applications on the card and
certify them without regard to what else is running on the card, while the
current practice would require a re-certification of all the software on
the card as a whole. Megabucks saved.

Jan

 

[Willem]

)> In embedded software, we frequently write to memory addresses that are
)> in turn mapped to hardware control registers. Early optimizer design
)> was frequently done by software folk not familiar with this practices,
)> often optimizing out writes to address that they didn't see being
)> later read.

Jan wrote:

) ..which is the correct thing to do, IMO. If you want such dead stores or
) loads to happen in any case, you need to tell the compiler the changed
) semantics of that value in any case. In fact, on a modern processor, even
) if the compiler did not optimize the memory operation away, it is quite
) likely it wouldn't happen at all or in time.
)
) Crippling the optimizer is the wrong solution to this problem.

Correct me if I'm wrong, but isn't it true that most compilers have some
kind of flag (like volatile) to indicate that such writes are not to be
optimized away ? And if not, that would be the way to go, wouldn't it ?


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Rod Davison]

<reply satirical_mode="on">
Actually, the use of Java on the Mars rover is quite brilliant because of
Java's write once run anywhere model.

This means that NASA can re-license the code to run forklifts, golf
carts,wheelchairs, or any conveyance that could have its own on board
JVM.

Just think of how all that extra licensing revenue will enable us to meet
the President's goal of landing the Democratic candidate for President on
the moon before the election and returning him within four years. More or
less.

Unless the rover was developed under the GPL?
</reply>

Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.

 

[David Gay]

First of all, obviously Java is not an operating system. It's an
application programming language or tool targeted to the production of
Internet (particularly browser applications). You also cannot
implement a true operating system using Java as your programming
language. If you doubt this, I'll hand you an 80586 chip with 128-Megs
of online memory and chuckle as you try!)

A logical conclusion from this statement is that you can't write a "true"
(wonder what that means?) operating system in Lisp. Oops. Symbolics.

Hint: when you're doing that, you add a few well chosen extensions which
you use in the appropriate places.

 

[Harry Conover]

Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding.

I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.

The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.

This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.

With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.

For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.

The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.

Harry C.

 

[Michael N. Christoff]

Jan C. Vorbrüggen <[email protected]> wrote in message

Sorry Jan, I couldn't locate the original source of the text you
quoted and to which I am responding.


I believe that accuracy of this statement depends entirely on the
degree of reaction latency that can be tollerated in the real time
system. Even at today's fantastic execution rates, critical real-time
must occur within only a few machine execution cycles.

The execution latency penalty imposed by my concept of a virtual
machine will, at least in my mind, knock it from consideration for
anything approaching that which is normally required for critical
real-time performance. Here often anything greater than a few
processor instruction cycle latency leads to a non-recoverable error
situation.

This is precisely why interrupt level service routines, fast device
drivers, and similar time-critical operations are generally
implemented in assembly or other low-level code optimized to minimize
the number and duration of required machine instruction executions.

With today's focus on high-level programming languages and software
implemented virtual machines, many people lose sight of the very
fundamental differences that exist between software that simply
executes quickly and real-time system software where interrupt level
response processing must be assured to be alway less than some
critical latency limit. Couple this with the fact that in most
real-time control and operating systems, these latency requirements
are often only a few microseconds and the need for very tightly coded
software becomes obvious.

For an example of real-time OS design, compare the kernel
implementation in something like Wind River's VxWorks RTOS vs. that of
a non-real-time OS such as early Unix or Microsoft Windows.
Particularly note the fact the the task scheduler in a real-time OS of
any reasonable complexity will be both dynamic priority weighted and
perform pre-emptive scheduling because you can't have a slow process
(like I/O) hogging the system and locking out tasks that need to
execute in milliseconds or microseconds.

The above and other considerations in real-time are what cause me to
believe that the utility of a virtual machine so very unrealistic for
RTOS use.

If you're interested into getting to the bottom of this, I'd suggest you
peruse the real time specification for java. That and other related
information can be found here.

http://www.rtj.org/

I'm sure it could address your questions better than I ever could. I'd be
interested to hear your comments.



l8r, Mike N. Christoff

 

[Michael N. Christoff]

"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."

"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."


http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm



l8r, Mike N. Christoff

 

[Joe \Nuke Me Xemu\ Foster]

"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."

"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."


http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm

Are they sure it's not just Sun's JVM taking a break to do a GC?

 

[Michael N. Christoff]

"Michael N. Christoff" <[email protected]> wrote in

Are they sure it's not just Sun's JVM taking a break to do a GC?

If they were using standard Java (ie: not a real-time version) that would
not be beyond the realm of possibility. Hopefully its something just as
recoverable. (Note: I'm pretty certain Java is not actually running on
the rover itself).



l8r, Mike N. Christoff

 

[Andrew Thompson]

message <|
| > "This is a serious problem. This is an extremely serious anomaly," said
Pete
| > Theisinger Spirit project manager.
| > "There is no single fault that explains all the observables."
| >
| > "...but Spirit was only transmitting "pseudo-noise", a random series of
| > zeroes and ones in binary code and not anything the scientists could
| > decipher."
| >
| >
| > http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm
|
| Are they sure it's not just Sun's JVM taking a break to do a GC?

Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).

In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)

 

[Uncle Al]

"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."

"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."

http://news.bbc.co.uk/1/hi/sci/tech/3421071.stm

NASA is renowned for its antenna failures - the Hubble space
telescope, Ulysses at Jupiter, and now their little radio-controlled
go-cart on Mars.

Uncle Al eagerly anticipates a Hummer-2 advert beginning with the $240
million pigmy brain fart that couldn't call home. Anticipating that
its working life would be less than 90 days because of dust
accumulating on its solar panels is also precious. Hey NASA, "blow
job."

One presumes the same engineering glitch is in the other rover.

 

[Berlin Brown]

The rover was programmed with Visual Basic 6.0, but Windows Update
zapped the MSVBVM60.DLL run-time. Obviously, all VB applications
should already have been trashed, redesigned, and rewritten in .NyET!

Maybe they should have used java....

Run the system through junit...

Engineers struggled to diagnose what was wrong with the rover. Among the
possible causes: a corruption of its software or computer memory.

Spirit is one-half of an $820 million mission. Its twin, Opportunity, is
expected to land on Mars late Saturday. The twin rovers are supposed to
examine the Red Planet's dry rocks and soil for evidence that it was
once wetter and more hospitable to life.

java.lang.RoverException(line: 10,345)


Dope?

 

[Joe \Nuke Me Xemu\ Foster]

news:[email protected]...

| Are they sure it's not just Sun's JVM taking a break to do a GC?

Unless, of course, the software was written
in something like C++ (as has been suggested[?],
and is more likely).

There are go-to-lunch slow garbage collectors for C++ too, such as
the "managed C++" abomination Microslop is trying to shove through
the ECMA. Apparently nothing is safe from the "embrace and extend"
standards pollution and proprietarization strategy.

In that case, would it be more likely caused by,
"dangling pointers to objects in deleted heaps"
perhaps? ;-)

That can happen when some chimp-coder can't quite comprehend RAII.
Another common fudgeup is to throw an exception from a destructor.

 

[Andrew Thompson]

|
| > | Are they sure it's not just Sun's JVM taking a break to do a GC?
| >
| > Unless, of course, the software was written
| > in something like C++ (as has been suggested[?],
| > and is more likely).
|
| There are go-to-lunch slow garbage collectors for C++ too, such as
| the "managed C++" abomination Microslop..

LOL - love that one Joe, I'll have to
add it to my list of MafiaSoft, M$,
Windoze and MicroBastard* ..

* Has a particularly Australian flavor.
Aussies enjoy that the second word
does not even derive from a word
that starts with the same/similar
letter. ;-)

 

[Rick Osborn]

I think they should turn it off and turn it on again.

 

[Joe \Nuke Me Xemu\ Foster]

I think they should turn it off and turn it on again.

They need to reinstall Winblows...

 

[Tony Hill]

Actually, academic debate aside, the success of the rover so far is a
welcome shot in the arm for the space program, especially after the
shuttle tragedy and previous Mars mission failures. In the cold harsh
light of the pragmatic dawn, if the rover works to spec, then using java
was a good decision, if not, then it was a poor decision. To quote the
scribe: all else is commentary.

Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.

 

[Joe \Nuke Me Xemu\ Foster]

"This is a serious problem. This is an extremely serious anomaly," said Pete
Theisinger Spirit project manager.
"There is no single fault that explains all the observables."

"...but Spirit was only transmitting "pseudo-noise", a random series of
zeroes and ones in binary code and not anything the scientists could
decipher."

"This behavior is by design."

 

[Joe \Nuke Me Xemu\ Foster]

Or perhaps more to the point, not using Java was a good decision!
hint: in case you missed it, the rover doesn't use any Java code, the
Java is all for manipulating the data received back from the Rover.

The rover was programmed with Visual Basic 6.0, but Windows Update
zapped the MSVBVM60.DLL run-time. Obviously, all VB applications
should already have been trashed, redesigned, and rewritten in .NyET!