Mars Rover Controlled By Java

Post by Michael N. Christoff
Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life.
http://news.com.com/2100-1007_3-5142220.html?tag=nefd_top
l8r, Mike N. Christoff

The software on earth is in java, but is the software running on the
thing itself java?

JavaJunkie

2004-01-17 05:08:34 UTC

Thats' correct. Look at
http://www.cnn.com/2004/TECH/space/01/16/space.mars.java.reut/index.html

Had it been running Microsoft .NET, the payload would be heavier due to more
memory needed to run Windows, the cost higher due to licensing fees NASA
would have to pay Bill Gates/Microsoft, and by now would be sending back the
"blue screen of death" instead of the martian surface!

The software on earth is in java, but is the software running on the
thing itself java?

mitch

2004-01-17 06:32:24 UTC

Read the article carefully. Java is being used to create 3D views of
terrain, and for command and control functions, ON EARTH. The last
paragraph correctly states that Wind River Systems made the embedded
software in the Spirit and Opportunity rovers. They run applications
created by JPL which execute on the VxWorks real-time operating system
(RTOS). I know this because a little of my work is in that RTOS - I
worked for Wind River until recently.

If you want more info on VxWorks, see the web site: www.windriver.com

The VxWorks RTOS also ran the Mars Lander and is in many other active
NASA probes like Stardust.

--mitch

Post by JavaJunkie
Thats' correct. Look at
http://www.cnn.com/2004/TECH/space/01/16/space.mars.java.reut/index.html
Had it been running Microsoft .NET, the payload would be heavier due to more
memory needed to run Windows, the cost higher due to licensing fees NASA
would have to pay Bill Gates/Microsoft, and by now would be sending back the
"blue screen of death" instead of the martian surface!

Post by Michael N. Christoff
Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a

low-cost

Post by Michael N. Christoff
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and

life.

Post by Michael N. Christoff
http://news.com.com/2100-1007_3-5142220.html?tag=nefd_top
l8r, Mike N. Christoff

The software on earth is in java, but is the software running on the
thing itself java?

Dalibor Hrg

2004-01-17 09:53:34 UTC

We can say that Java is most useful language on Mars today :))) You know,
the time of .NET is coming while Java has already took its place in
history. Nothing can change that, Java is simply great thing!

I was thinking, NASA could run some servers which will present Spirit's 3D
visualization. They could use Java3D in some applet so anybody interested
could navigate path that Spirit has traveled. It will be nice to see that.
How many cameras Spirit has anyway?

I was also thinking why all robots or searchers have wheels, I mean if they
are doing some research on land ok than, but it will be easier to use some
flying robot like small helicopter or something for making map. It will have
its platform with solar panels, it can go faster and I think travel lot more
distance. The platform can have wheels so it can move. The helicopter can be
useful to analyze around the platform and navigate platform. Let's say Sprit
and small robo-copter will be ideal combination. It's just suggestion.

At the end flying robots will depend on Mars's atmosphere, right?

Post by mitch
Read the article carefully. Java is being used to create 3D views of
terrain, and for command and control functions, ON EARTH. The last
paragraph correctly states that Wind River Systems made the embedded
software in the Spirit and Opportunity rovers. They run applications
created by JPL which execute on the VxWorks real-time operating system
(RTOS). I know this because a little of my work is in that RTOS - I
worked for Wind River until recently.
If you want more info on VxWorks, see the web site: www.windriver.com
The VxWorks RTOS also ran the Mars Lander and is in many other active
NASA probes like Stardust.
--mitch

Post by Michael N. Christoff
Java, the software developed by Sun Microsystems in the mid-1990s as a
universal operating system for Internet applications, gave NASA a

low-cost

Post by Michael N. Christoff
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and

life.

Post by Michael N. Christoff
http://news.com.com/2100-1007_3-5142220.html?tag=nefd_top
l8r, Mike N. Christoff

The software on earth is in java, but is the software running on the
thing itself java?

Dave Harris

2004-01-17 12:32:00 UTC

Post by Dalibor Hrg
We can say that Java is most useful language on Mars today :)))

Err, I read him as saying Java is /not/ on Mars today.

-- Dave Harris, Nottingham, UK

Jan Panteltje

2004-01-17 16:52:45 UTC

On a sunny day (Sat, 17 Jan 2004 12:32 +0000 (GMT Standard Time)) it happened

Post by Dave Harris

Post by Dalibor Hrg
We can say that Java is most useful language on Mars today :)))

Err, I read him as saying Java is /not/ on Mars today.

Correct, and the fact that we already have pics proves that.

Uncle Al

2004-01-17 15:51:13 UTC

Dalibor Hrg wrote:
[snip]

Post by Dalibor Hrg
I was also thinking why all robots or searchers have wheels, I mean if they
are doing some research on land ok than, but it will be easier to use some
flying robot like small helicopter or something for making map. It will have
its platform with solar panels, it can go faster and I think travel lot more
distance. The platform can have wheels so it can move. The helicopter can be
useful to analyze around the platform and navigate platform. Let's say Sprit
and small robo-copter will be ideal combination. It's just suggestion.

[snip]

Local atmospheric pressure is 7-10 torr. Earth sea level is 760
torr. How many planes do you know that cruise at 100,000 feet absent
any oxygen at all? Martian aircraft are a bad dream.

--
Uncle Al
http://www.mazepath.com/uncleal/
(Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!

Andrew Thompson

2004-01-17 16:13:34 UTC

"Uncle Al" <***@hate.spam.net> wrote in message news:***@hate.spam.net...
| Dalibor Hrg wrote:
| [snip]
...
| > flying robot like small helicopter or something for making
map. It will have
| > its platform with solar panels, it can go faster and I think
travel lot more
| > distance.
...
| Local atmospheric pressure is 7-10 torr. Earth sea level is
760
| torr. How many planes do you know that cruise at 100,000 feet
absent
| any oxygen at all?

Why mention oxygen specifically?
The solar panels mentioned would have no
problem with the complete absence of oxygen.

..Though a battery powered chopper would
still be little more effective than one that
uses internal combustion.

And getting back to the original
thrust of this thread.

No, even if it were possible to make
a craft that could fly in Mars' atmosphere,
that would not be controlled by Java either
as it would violate Sun's license.

[ Why the heck was this cross-posted to
sci.physics? Some of the other groups are
borderline, but that one's off the wall.. ]

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

Manolis Christodoulou

2004-01-17 17:27:31 UTC

Post by Andrew Thompson
No, even if it were possible to make
a craft that could fly in Mars' atmosphere,
that would not be controlled by Java either
as it would violate Sun's license.

Is the java License valid in other planets? :-)

chris

2004-01-17 22:16:57 UTC

Post by Andrew Thompson
No, even if it were possible to make
a craft that could fly in Mars' atmosphere,
that would not be controlled by Java either
as it would violate Sun's license.

Irrelevant. If you really do see Java in space, it won't be made by Sun.

http://www.aicas.com/press/pr_12_en_24-Oct-03.html

[sci.physics deleted from X-postings]

--
Chris Gray ***@kiffer.eunet.be

seemanta dutta

2004-01-21 04:57:04 UTC

<snip>

Post by Andrew Thompson
Why mention oxygen specifically?
The solar panels mentioned would have no
problem with the complete absence of oxygen.

My dear friend, planes need atmosphere not only for combustion but
also for generating the required lift by its wings or copter blades or
whatever. A rarefied atmosphere would not be able to generate enough
lift at a decent velocity like on earth. of course by increasing the
velocity several times we can generate some lift, but that would be a
totally wasteful use of energy.

Besides to keep a copter in the air it woulf consume a great deal of
energy which could be otherwise utilised for some other purpose.

Post by Andrew Thompson
..Though a battery powered chopper would
still be little more effective than one that
uses internal combustion.

again battery power does not solve the probelm of generating enough
lift in a rarefied atmosphere.

regards,
Seemanta Dutta

Michael Borgwardt

2004-01-21 08:51:17 UTC

Post by seemanta dutta

Post by Andrew Thompson
Why mention oxygen specifically?
The solar panels mentioned would have no
problem with the complete absence of oxygen.

My dear friend, planes need atmosphere not only for combustion but
also for generating the required lift by its wings or copter blades or
whatever.

So he is right: oxygen does not, specifically, matter.

Post by seemanta dutta
A rarefied atmosphere would not be able to generate enough
lift at a decent velocity like on earth. of course by increasing the
velocity several times we can generate some lift, but that would be a
totally wasteful use of energy.

Don't forget that the necessary lift is *also* much lower on Mars
since it has only one tenth the mass!

m***@cars3.uchicago.edu

2004-01-21 09:12:23 UTC

Post by Michael Borgwardt

Post by seemanta dutta

Post by Andrew Thompson
Why mention oxygen specifically?
The solar panels mentioned would have no
problem with the complete absence of oxygen.

My dear friend, planes need atmosphere not only for combustion but
also for generating the required lift by its wings or copter blades or
whatever.

So he is right: oxygen does not, specifically, matter.

Don't forget that the necessary lift is *also* much lower on Mars
since it has only one tenth the mass!

Well, the gravity is not proporitonal to mass alone. It's radius is
smaller as well, so its gravity, on surface, is doen only by a factor
of 2 or so. Its atmospheric density, on the other hand, is down by
more than two orders of magnitude. So, the necessary lift is lower by
much less than the available lift.

Mati Meron | "When you argue with a fool,
***@cars.uchicago.edu | chances are he is doing just the same"

Dale King

2004-01-21 15:55:15 UTC

Post by m***@cars3.uchicago.edu
Well, the gravity is not proporitonal to mass alone. It's radius is
smaller as well, so its gravity, on surface, is doen only by a factor
of 2 or so.

For the record, Mars' surface gravity is 0.38 (about 1/3) times Earth's
gravity.

--
Dale King

m***@cars3.uchicago.edu

2004-01-21 20:23:37 UTC

Post by Dale King

Post by m***@cars3.uchicago.edu
Well, the gravity is not proporitonal to mass alone. It's radius is
smaller as well, so its gravity, on surface, is doen only by a factor
of 2 or so.

For the record, Mars' surface gravity is 0.38 (about 1/3) times Earth's
gravity.

Good, So, my estimate is fine.

Mati Meron | "When you argue with a fool,
***@cars.uchicago.edu | chances are he is doing just the same"

Programmer Dude

2004-01-21 16:41:40 UTC

of course by increasing the velocity several times we can generate
some lift, but that would be a totally wasteful use of energy.

One can also increase wing area. This is, e.g., why 747s can land
so amazingly slowly for such a big bird.

--
|_ CJSonnack <***@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL |
|_____________________________________________|_______________________|

Randy Howard

2004-01-21 21:22:13 UTC

Post by Programmer Dude

of course by increasing the velocity several times we can generate
some lift, but that would be a totally wasteful use of energy.

One can also increase wing area. This is, e.g., why 747s can land
so amazingly slowly for such a big bird.

Flaps and slats (particularly on large aircraft) make a huge difference.

This is somewhat interesting, although the animation is fairly weak.
http://www.grc.nasa.gov/WWW/K-12/airplane/flap.html

[quote]
During takeoff and landing the airplane's velocity is relatively low.
To keep the lift high (to avoid objects on the ground!), airplane designers
try to increase the wing area and change the airfoil shape by putting some
moving parts on the wings' leading and trailing edges. The part on the leading
edge is called a slat, while the part on the trailing edge is called a flap.
The flaps and slats move along metal tracks built into the wings. Moving the
flaps aft (toward the tail) and the slats forward increases the wing area.
Pivoting the leading edge of the slat and the trailing edge of the flap
downward increases the effective camber of the airfoil, which increases the
lift. In addition, the large aft-projected area of the flap increases the drag
of the aircraft. This helps the airplane slow down for landing.
[/quote]

--
Randy Howard
2reply remove FOOBAR

Programmer Dude

2004-01-21 21:51:34 UTC

Post by Randy Howard

Post by Programmer Dude
One can also increase wing area. This is, e.g., why 747s can land
so amazingly slowly for such a big bird.

Flaps and slats (particularly on large aircraft) make a huge
difference.

One reason they make a diff on large aircraft is the proportional
difference in increasing the wing area of an already large wing.

Keep in mind that ALL aircraft land with flaps. 747s are slower
because their wings are bigger to begin with.

Post by Randy Howard
[quote]
...To keep the lift high (to avoid objects on the ground!), airplane
designers try to increase the wing area and change the airfoil shape
...

Yep. Airfoil shape is another mechanism. High camber affects
performance, so isn't used other than at slow speeds (IIUC).
Compare this to fighter jets with itty bitty razor-sharp wings.
Those babies need serious speed to fly at all!

Randy Howard

2004-01-21 23:45:58 UTC

Post by Programmer Dude
One reason they make a diff on large aircraft is the proportional
difference in increasing the wing area of an already large wing.
Keep in mind that ALL aircraft land with flaps.

That's simply not true. Not only do some airplane designs simply not
have flaps, but accomplished pilots practice flapless landings in
case of a system failure.

Numerous early Piper aircraft had no flaps at all, and flew very
well. Same is true for quite a few other designs.

Even exotic special purpose modern aircraft, such as the Extra 300
series have no flaps.

--
Randy Howard
2reply remove FOOBAR

Programmer Dude

2004-01-23 17:37:51 UTC

Post by Randy Howard

Post by Programmer Dude
Keep in mind that ALL aircraft land with flaps.

That's simply not true.

You're right, of course. I had in mind the big commercial jets
when I was comparing the landing speed of 747s with others of the
same general class.

Post by Randy Howard
...accomplished pilots practice flapless landings in
case of a system failure.

Absolutely.

mitch

2004-01-17 22:19:24 UTC

Post by Uncle Al
Local atmospheric pressure is 7-10 torr. Earth sea level is 760
torr. How many planes do you know that cruise at 100,000 feet absent
any oxygen at all? Martian aircraft are a bad dream.

Hmm. Then the test of a Mars glider plane back in August of 2001 was
just a bad dream? ;-) Work has begun on a propellered version of the
glider cited below. Enjoy.

--mitch
----------------------------

http://amesnews.arc.nasa.gov/releases/2001/01_58AR.html

Michael Mewhinney Aug. 13, 2001
NASA Ames Research Center, Moffett Field, CA
Phone: 650-604-5026 or 604-9000
***@mail.arc.nasa.gov or ***@mail.arc.nasa.gov

RELEASE: 01-58AR

AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE

Soaring gracefully down to Earth from a balloon floating 101,000 feet high
above Oregon, a NASA prototype of an airplane that someday may fly over
Mars successfully completed a high-altitude flight test this week.

Conducted at Oregon's Tillamook airport by the Kitty Hawk 3 project at NASA
Ames Research Center, Moffett Field, CA, the test was designed to validate
the aerodynamic performance of the prototype. Nicknamed "Orville" after
one of the famed Wright brothers who first flew on Dec. 17, 1903, the NASA
731 glider was dropped from a helium-filled balloon that towed it up to an
altitude of 101,000 feet - the highest ever for such a test - before
releasing it. Engineers and scientists hailed the test as a great success.

"It was a great flight and everything went really well. It appears that we
realized all of our test objectives," exclaimed a jubilant Andy Gonzales,
an Ames aerospace engineer who served as the flight test director.
Low-altitude tests of NASA 729, another prototype called "Wilbur," were
conducted last month at Ames.

"Mars has always fascinated people," said Larry Lemke, an aerospace
engineer at NASA Ames who serves as Ames' project manager for advanced Mars
mobility concepts, which include airplanes as well as other systems.
"Every time we send a mission up there, we come back with fascinating
discoveries."

According to Lemke, a Mars airplane is an idea whose time has come. "The
Mars airplane is an idea that has been around for about 25 years, and over
the past five years or so, it has been growing in popularity," he said. "I
think a Mars airplane will play a role in exploring the Red Planet."

Conventional in appearance, the Mars airplane concept developed by Ames
engineers features a long, straight wing and twin tails in the rear. The
remote-controlled glider tested in Oregon featured an approximately
four-foot-long fuselage and an eight-foot wing span.

"The flying we have successfully completed in Oregon is very similar to the
flying that we will be doing over Mars during a productive exploration
mission," Lemke said. "One unique aspect of flying a Mars mission with an
airplane is that it must be constructed in a fold-up configuration in order
to fit inside a spacecraft."

In its future configuration for Mars, the aircraft is expected to have its
own propeller propulsion system capable of operating in the Mars
atmosphere, which is comprised mostly of carbon dioxide. It will also
carry a variety of sophisticated instruments to observe and conduct science
experiments.

"The possibility of life on Mars is a very hot topic and an interesting
question, so I'm sure you will find instruments on board that are designed
to find signs of water on Mars, which is necessary for life," Lemke said.

"In addition, we would have a large array of cameras on the airplane to be
able to see large areas of the Mars terrain in very high resolution," Lemke
said. He said the cameras aboard the aircraft would be so precise, they
could see objects on Mars as small as the size of a quarter. "I think the
images will be stunning," he said. "During a Mars airplane mission, we will
be able to view the planet at very close proximity and this will convey to
the public that there is a real planet there, not just an abstract."

"Our test flight at Tillamook airport showed the airplane's flight was very
smooth and stable which makes for a good platform for science instruments,"
said Gonzales.

Ames engineers predict the next few years will be challenging, as they
prepare for a potential mission to Mars. "We will be expanding the envelope
and developing a much more complex aircraft for exploring Mars," Lemke
said. The next step will be to develop a Mars airplane model with folding
wings and later, one with a propeller propulsion system.

-- end --

Note to Broadcasters: A video file related to this news release is
scheduled for distribution via satellite on NASA Television on August 14,
2001. Because feed times and the schedule are subject to change, please
check the NASA TV video file line-up on the web at
ftp://ftp.hq.nasa.gov/pub/pao/tv-advisory/nasa-tv.txt

NASA TV is available on GE-2, transponder 9C at 85 degrees west longitude,
with vertical polarization; frequency is on 3880.0 megahertz, with audio on
6.8 megahertz. For general questions about the video file, call NASA
Headquarters, Washington, DC: Fred Brown at 202/358-0713

Uncle Al

2004-01-17 22:46:45 UTC

Post by mitch

Hmm. Then the test of a Mars glider plane back in August of 2001 was
just a bad dream? ;-) Work has begun on a propellered version of the
glider cited below. Enjoy.
AMES COMPLETES SUCCESSFUL TEST OF MARS AIRPLANE PROTOTYPE

The empirical fact is that lowland Martian air pressure is 7-10 torr.
The is equivalent to 120,000-100,000 feet terrestrial altitude. If
the silly thing will be diddling at even 1000 ft altitude Martian, the
air will be thinner. I don't care if Hillary Ramrod Clinton left a
big warm wetspot on the chute prior to deployment. Stuff doesn't fly
that high - certainly absent oxygen in the intake.

"Ye canna break the laws of physics."

The Concorde flew at 60,000 feet and gulped air like a madman. The
U-2 did 75,000 feet, breathed air, and it was a bitch to fly. The
SR-71 Blackbird could barely do 100,000 feet while at Mach 3+ with its
cockpit windshield simmering at 620 F. It drank 8000 gallons/hr of
fuel. It breathed 6 million ft^3 of air/minute.

Post by mitch
Soaring gracefully down to Earth from a balloon floating 101,000 feet high
above Oregon, a NASA prototype of an airplane that someday may fly over
Mars successfully completed a high-altitude flight test this week.

Yeah, right. They have an airfoil that works in vacuum. What is its
payload - one NASA decal? Learn the difference between Official Truth
and real world truth.

[snip]

--
Uncle Al
http://www.mazepath.com/uncleal/qz.pdf
http://www.mazepath.com/uncleal/eotvos.htm
(Do something naughty to physics)

Rupert Pigott

2004-01-17 23:00:35 UTC

"Uncle Al" <***@hate.spam.net> wrote in message news:***@hate.spam.net...

[SNIP]

Post by Uncle Al
The empirical fact is that lowland Martian air pressure is 7-10 torr.
The is equivalent to 120,000-100,000 feet terrestrial altitude. If
the silly thing will be diddling at even 1000 ft altitude Martian, the

According to that link they've tested it at over 100,000 ft
already. Cute idea, but I figure the air-ship type option
may be more robust and easier to deploy - plus if something
momentarily breaks it's less like to fall out of the sky.

Cheers,
Rupert

Andrew Thompson

2004-01-17 23:22:38 UTC

"Rupert Pigott" <***@dark-try-removing-this-boong.demon.co.uk>
wrote in message news:***@saucer.planet.gong...
| "Uncle Al" <***@hate.spam.net> wrote in message
| news:***@hate.spam.net...
|
| [SNIP]
|
| > The empirical fact is that lowland Martian air pressure is
7-10 torr.
| > The is equivalent to 120,000-100,000 feet terrestrial
altitude. If
| > the silly thing will be diddling at even 1000 ft altitude
Martian, the
|
| According to that link they've tested it at over 100,000 ft
| already. Cute idea, but I figure the air-ship type option
| may be more robust and easier to deploy - plus if something
| momentarily breaks it's less like to fall out of the sky.

This topic was discussed recently on sci.space.tech.
One of the problems identified for heavier than..
atmosphere craft was the *runway length required
to take-off or land.

[ And to those that would jump in and suggest
keeping it aloft continuously, that is impractical
with sandstorms, ..even assuming you could squeeze
a 'little' RTG into it, and still get it off the ground. ]

Balloon, or better still, orbiter with a bloody
good telescope. No dust, no sand, no runways
to deal with and you can cover far more area.

* Well, of _course_ they would be using all
those really _long_ runways built on Mars
during WWII. ;-)

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

Jon Leech

2004-01-18 05:58:55 UTC

Post by Uncle Al
Local atmospheric pressure is 7-10 torr. Earth sea level is 760
torr. How many planes do you know that cruise at 100,000 feet absent
any oxygen at all?

The AeroVironment Helios Prototype, for one:

http://www.aerovironment.com/area-aircraft/unmanned.html

Post by Uncle Al
Martian aircraft are a bad dream.

No more than Mars sample return or numerous other challenging but
entirely feasible tasks.

Jon
__@/

Jan Panteltje

2004-01-17 16:52:45 UTC

On a sunny day (Sat, 17 Jan 2004 10:53:34 +0100) it happened "Dalibor Hrg"

Post by Dalibor Hrg
We can say that Java is most useful language on Mars today :))) You know,
the time of .NET is coming while Java has already took its place in
history. Nothing can change that, Java is simply great thing!

Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

2004-01-17 19:33:21 UTC

Post by Jan Panteltje

Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

since hardware speed grows very quick, it is not a real problem!
____________

http://reader.imagero.com the best java image reader.

Jan Panteltje

2004-01-18 01:11:35 UTC

On a sunny day (Sat, 17 Jan 2004 20:33:21 +0100) it happened "ak"

Post by ak

Post by Jan Panteltje

Post by Dalibor Hrg
We can say that Java is most useful language on Mars today :))) You

know,

Post by Jan Panteltje

Post by Dalibor Hrg
the time of .NET is coming while Java has already took its place in
history. Nothing can change that, Java is simply great thing!

Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

since hardware speed grows very quick, it is not a real problem!

Ridiculous
10 years behind always on asm and C

Richard Heathfield

2004-01-18 05:34:08 UTC

Post by ak

Post by Jan Panteltje
Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

since hardware speed grows very quick, it is not a real problem!

Past performance is no guarantee of future success. Those who live by
Moore's Law will, ultimately, die by it.

--
Richard Heathfield : ***@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

Tony Hill

2004-01-17 21:28:13 UTC

On Sat, 17 Jan 2004 16:52:45 GMT, Jan Panteltje

Post by Jan Panteltje
On a sunny day (Sat, 17 Jan 2004 10:53:34 +0100) it happened "Dalibor Hrg"

Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

You know, believe it or not, Java isn't all that slow. Here are a
couple of tests comparing different languages for very simple
algorithms:

http://www.bagley.org/~doug/shootout/index2.shtml

http://osnews.com/story.php?news_id=5602

While these simple tests might not hit on some of the weaknesses of a
JIT language like Java, they do tend to indicate that the performance
for most tests isn't all that bad.

That being said, the fact remains that Java is NOT being used on Mars
today. The Java stuff the original article talked about was all
earth-based stuff. In fact, it wasn't even the thing that was getting
the data from the Mars rover, simply the component that let people
view the data after it had been received.

The code on the rover wasn't specified, but it's most likely C/C++ as
that is the primary development language for Wind River VxWorks. I'm
not even sure if that OS has Java support, though even if it did it
would be a BAD choice. Java is NOT designed with real-time operating
systems in mind. It's a fine language for what it is, but it's not
really a suitable choice for this application. Ada might actually be
the best choice, as this is the sort of thing that language was
designed for, but C/C++ is a good alternative that is widely supported
and well known.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

Michael N. Christoff

2004-01-18 00:42:56 UTC

Post by Tony Hill
On Sat, 17 Jan 2004 16:52:45 GMT, Jan Panteltje

Post by Jan Panteltje
On a sunny day (Sat, 17 Jan 2004 10:53:34 +0100) it happened "Dalibor Hrg"

Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

You know, believe it or not, Java isn't all that slow. Here are a
couple of tests comparing different languages for very simple
http://www.bagley.org/~doug/shootout/index2.shtml
http://osnews.com/story.php?news_id=5602
While these simple tests might not hit on some of the weaknesses of a
JIT language like Java, they do tend to indicate that the performance
for most tests isn't all that bad.
That being said, the fact remains that Java is NOT being used on Mars
today. The Java stuff the original article talked about was all
earth-based stuff. In fact, it wasn't even the thing that was getting
the data from the Mars rover, simply the component that let people
view the data after it had been received.
The code on the rover wasn't specified, but it's most likely C/C++ as
that is the primary development language for Wind River VxWorks. I'm
not even sure if that OS has Java support, though even if it did it
would be a BAD choice. Java is NOT designed with real-time operating
systems in mind.

That is correct. However, standard Java is also not a good choice for cell
phones. You need Java Micro edition (J2ME) for this. On that note, there
is much work being done on developing a version of Java for real time
systems.

l8r, Mike N. Christoff

Jan Panteltje

2004-01-18 01:11:35 UTC

On a sunny day (Sat, 17 Jan 2004 21:28:13 GMT) it happened Tony Hill

Post by Tony Hill
You know, believe it or not, Java isn't all that slow. Here are a
couple of tests comparing different languages for very simple

OK, but my latest test on THAT java mars rover soft ran 1.3 frames / second
on a 1 GHz PC.
Before it crashed mind you.

Post by Tony Hill
from the rovers will be provided and can be loaded into the program.
http://mars.telascience.org/home/
"The Jet Propulsion Laboratory has released Maestro, a public version
of the primary software tool used by NASA scientists to operate the
Mars Exploration Rovers. Anyone can download Maestro for free from
http://mars.telascience.org/ and use it to follow along with the
rovers' progress during the mission. You can use Maestro to view
pictures from Mars in 2D and 3D and create simplified rover activity
plans. During the mission, updates will be released for Maestro
containing the latest images from Mars."

Me replying:
OK I downloaded the Linux version last night (I am in Europe),
realizing after it turned out to be a 2 1/2 hour download on a V90 modem,
that I really must be confident that lander worked this time....

Anyways it is based on java rle, the install script has some errors,
so you can not run it as the indicated executable,
but I had to run it as (I untarred it in /video/compile/maestro/ )
/video/compile/maestro/R2004_01-Public-Linux/JPL/SAP/bin/WITS
while 'SAP', that should start it (in /usr/local/bin), points to
SAP -> /video/compile/maestro/R2004_01-Public-Linux/WITS

So directory JPL/bin is missing from the softlink in /usr/local/bin
Also the install script 'forgets' to do
tar -xvf mer.tar
in
/video/compile/maestro/R2004_01-Public-Linux/JPL/SAP/WITS-db
so that you actually see some data.
Because of java (likely) the thing is slower then a dead snail glued with
superglue to a scrapped Apollo.
I followed the intro to the point where it had to move to a target, then it
froze with this message in the console:

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x400C32F7
Function=memcpy+0x27
Library=/lib/libc.so.6

Current Java thread:

****************
Another exception has been detected while we were handling last error.
Dumping information about last error:
ERROR REPORT FILE = (N/A)
PC = 0x0x400c32f7
SIGNAL = 11
FUNCTION NAME = memcpy
OFFSET = 0x27
LIBRARY NAME = /lib/libc.so.6
Please check ERROR REPORT FILE for further information, if there is any.
Good bye.

So, 1.3 frames / second before it crashed, and this system plays live video
at normal speed no problem.
But THAT code is written in asm and C.
I remember the old vrml browsers (was there al the way from the beginning).
After some of these got ported to Java it was a factor 10 slower (at least).
And NO reason in the world to do that, portability of good C code is excellent.
Java is a mistake.

Michael N. Christoff

2004-01-21 17:51:30 UTC

Post by Tony Hill
The code on the rover wasn't specified, but it's most likely C/C++ as
that is the primary development language for Wind River VxWorks. I'm
not even sure if that OS has Java support, though even if it did it
would be a BAD choice. Java is NOT designed with real-time operating
systems in mind. It's a fine language for what it is, but it's not
really a suitable choice for this application. Ada might actually be
the best choice, as this is the sort of thing that language was
designed for, but C/C++ is a good alternative that is widely supported
and well known.

Seems like Java may well be used on the actual rover in the future:

Jim Sculley wrote:
<quote>
In any event this entire discussion has ignored the Realtime
Specification for Java, implementations of which are being used in
mission critical apps, such as control systems for a future Mars rover:

http://www.opengroup.org/rtforum/uploads/40/2930/OpenGroup_Golden_Gate_May01
-v05.pdf

Jim S.
</quote>

l8r, Mike N. Christoff

Alan Balmer

2004-01-20 18:49:32 UTC

On Sat, 17 Jan 2004 16:52:45 GMT, Jan Panteltje

Post by Jan Panteltje
On a sunny day (Sat, 17 Jan 2004 10:53:34 +0100) it happened "Dalibor Hrg"

Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

Haven't tried it lately, have you ;-)

--
Al Balmer
Balmer Consulting
***@att.net

Jan Panteltje

2004-01-20 23:26:35 UTC

On a sunny day (Tue, 20 Jan 2004 11:49:32 -0700) it happened Alan Balmer

Post by Tony Hill
On Sat, 17 Jan 2004 16:52:45 GMT, Jan Panteltje

Post by Jan Panteltje
On a sunny day (Sat, 17 Jan 2004 10:53:34 +0100) it happened "Dalibor Hrg"

Java is the worst thing that could happen to computing since the
invention of the chuwing gum hard disk.
It is slow, slow, slow, slow, SLOW, and not to mention slow.
And on top of that it is slow.

Haven't tried it lately, have you ;-)

Oh yes I did, but nervous Jave people start spamming my email
that I really *should not mention Java is slow*, well, read my other post
in this tread.
And THAT was written by NASA.
Penty of stuff around to show it, get real.

Post by Tony Hill
--
Al Balmer
Balmer Consulting

mmm
Solutions of Yesterday already NOW on your desktop with JAVA (snailmark).
Sorry

Ken Hagan

2004-01-21 10:11:07 UTC

Would it be *on-topic* to query the relevance of this to...

comp.arch
comp.distributed
comp.lang.java
comp.lang.java.programmer
comp.object
comp.programming
comp.theory
sci.physics

I'm all for serendipity and all that, and I've learned all sorts
of things from off-topic threads, but I think the OP's claim (and
hence the official subject of the thread) was shot down with the
first or second reply and we've given aircraft and Java advocacy
a good run now.

Stefan Monnier

2004-01-20 19:07:16 UTC

And that's why it's such an important step forward: it makes it possible for
people to realize that speed is not all that important when choosing
a programming language.

Now that we've taken this step, we can start to think about the next step:
focus on safety and correctness.

Stefan

Ashlie Benjamin Hocking

2004-01-20 21:34:19 UTC

Post by Stefan Monnier

And that's why it's such an important step forward: it makes it possible for
people to realize that speed is not all that important when choosing
a programming language.
focus on safety and correctness.

Actually, speed is very often an important aspect. The question is,
speed of what? If you spent five days writing/debugging a program in
C++ that could be written in two hours in LISP (for example), and the
program is only going to be used for a single experiment or set of
experiments, than most likely the improvement in performance that you
got by writing it in C++ is offset by the time spent writing/debugging
it. Obviously, as been said several times, it depends on what the
language is being used for. If the software is for security-critical
uses, C++ is probably a bad choice. If the software is for cracking a
particular encryption algorithm, C might be a very good choice. (Of
course, assembly might be even better!)

---------------------------------------------------------------------
| "Good and evil both increase at compound
Ben Hocking, Grad Student | interest. That is why the little
***@cs.virginia.edu | decisions you and I make every day are of
| such infinite importance." - C. S. Lewis
---------------------------------------------------------------------

Jan Panteltje

2004-01-20 23:26:35 UTC

On a sunny day (Tue, 20 Jan 2004 19:07:16 GMT) it happened Stefan Monnier

Post by Stefan Monnier

How safe is a car that cannot accelerate (when needed).
How correct is a solution that runs 10x slower then other ones.
(like web browser).
What does it give us, so you cannot program with pointers, so
you do not want to learn that, so you use java.
Popups, webcrap...
Or use 10 x power for the same final speed, efficient?
Java is as safe as the one who programs with it.
If you forget (because you think it is so safe) about any security issues,
then your eventual lack of knowledge about these issues will break
your code security.
I cannot really think of one useful application of Java except
burning it.
It is like BASIC, except slower, and less used.
Hey I am not just pestering, it is TRUE.
NOTHING is slower then java.

Stefan Monnier

2004-01-20 23:44:11 UTC

Post by Jan Panteltje
How safe is a car that cannot accelerate (when needed).
How correct is a solution that runs 10x slower then other ones.
(like web browser).
What does it give us, so you cannot program with pointers, so
you do not want to learn that, so you use java.
Popups, webcrap...
Or use 10 x power for the same final speed, efficient?

Why don't you go and learn about programming languages (and their history)?

Stefan

B***@uib.no

2004-01-21 13:19:44 UTC

I think most people have that impression either by playing with Java 1.0
(or listening to those who have), or by using Swing applications.

Newer Java versions and graphical applications using ie. SWT perform
the same as native C/Fortran applications. In fact, the new Hotspot
optimizer in 1.4 is quite good at numerical codes too. For some large
scale computations, my Java codes perform identical to Fortran codes,
with the added benefits of readability and maintainability, not to
mention trivial cross-platform deployment (from my desktop to the local
supercomputer, with excellent scalability).

I might add that Java w/Hotspot quite often outperforms vanilla C
codes, it's only when adding lots of optimization flags to the compiler
that the performance gap closes.

--
Bjørn-Ove Heimsund
Centre for Integrated Petroleum Research
University of Bergen, Norway

Jan C. Vorbrüggen

2004-01-21 12:32:06 UTC

Post by B***@uib.no
Newer Java versions and graphical applications using ie. SWT perform
the same as native C/Fortran applications. In fact, the new Hotspot
optimizer in 1.4 is quite good at numerical codes too.

While that is likely true, ...

Post by B***@uib.no
For some large
scale computations, my Java codes perform identical to Fortran codes,

Really? Even if you compile with optimization?

Post by B***@uib.no
with the added benefits of readability and maintainability, not to
mention trivial cross-platform deployment (from my desktop to the local
supercomputer, with excellent scalability).

I consider a reasonably well-written F95 program to be very maintainable
and more portable than Java - if only for the fact that there's only one
F95 standard all compilers are written to, while there are several
incompatible (in various ways) Java "standards" around, not to mention
the different thread semantics of different implementations.

Post by B***@uib.no
I might add that Java w/Hotspot quite often outperforms vanilla C
codes, it's only when adding lots of optimization flags to the compiler
that the performance gap closes.

For any modern compiler of a 3GL language, not compiling with (the equivalent
of) -fast is grossly negligent.

Jan

B***@uib.no

2004-01-21 16:26:07 UTC

Post by B***@uib.no
For some large
scale computations, my Java codes perform identical to Fortran codes,

Really? Even if you compile with optimization?

Yes, but I might add that the things I do are not easily vectorizable
(sparse matrix calculations). For dense array computations, a good
compiler can do fancy unrolling tricks and other things which is not
(yet) available in Java nor in Hotspot.

It's very easy to create unmaintainable code in any language, Java is no
exception. It's just that Java doesn't have a 40 year legacy baggage,
and encourages good design practices. Java seems to be well recieved
in some computer science institutes as well, especially as an
introduction to OO programming.

On the portability side, I have had issues porting some F95 codes
between compilers, both of which had different ideas how the standard
were to be interpreted (and the compilers were quite new too). F77
compiles nicely, though.

Post by Jan C. VorbrÃ¼ggen
incompatible (in various ways) Java "standards" around, not to mention
the different thread semantics of different implementations.

Since Java 1.2, I have yet to encounter any issues with thread
implementations, be it on AIX, Solaris, Linux or Windows. There are
of course some more issues relating to thread local storage and
caching, but the semantics of this is being worked out (for Java 1.5)

Post by B***@uib.no
I might add that Java w/Hotspot quite often outperforms vanilla C
codes, it's only when adding lots of optimization flags to the compiler
that the performance gap closes.

For any modern compiler of a 3GL language, not compiling with (the equivalent
of) -fast is grossly negligent.

Agreed. But many folks around here run their codes compiled with
"f77 -g" (not that I do that, of course :-)

--
Bjørn-Ove Heimsund
Centre for Integrated Petroleum Research
University of Bergen, Norway

Richard Maine

2004-01-21 16:55:20 UTC

Post by Jan C. VorbrÃ¼ggen
For any modern compiler of a 3GL language, not compiling with (the equivalent
of) -fast is grossly negligent.

A few years ago, I was asked to help with improving the performance of
a major production code here. The author of the code didn't even
know how to turn on the optimizer. I mean turning on the optimizer
at all, even with a simple -O, much less experimenting with the other
settings. I was a bit shocked that they felt the need to call for
help and hadn't even tried that. This was from a supposedly
professional full-time programmer and was in a code that had gone
through all the formal development process (for what little that
was actually worth :-() and was in production use.

But then, I found plenty of other problems also. I suppose it
figures. :-(

It was a Fortran code, but the major problems didn't have much to
do with the language. If you are sufficiently clueless, you can
manage to express that cluelessness in any language.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Ashlie Benjamin Hocking

2004-01-21 19:18:11 UTC

If you are sufficiently clueless, you can manage to express that
cluelessness in any language.

I think this is a quote worthy of a .sig file. (I'm assuming this is a
Richard Maine original?)

---------------------------------------------------------------------
| "Good and evil both increase at compound
Ben Hocking, Grad Student | interest. That is why the little
***@cs.virginia.edu | decisions you and I make every day are of
| such infinite importance." - C. S. Lewis
---------------------------------------------------------------------

Toon Moene

2004-01-21 22:10:55 UTC

Post by Ashlie Benjamin Hocking

If you are sufficiently clueless, you can manage to express that
cluelessness in any language.

I think this is a quote worthy of a .sig file. (I'm assuming this is a
Richard Maine original?)

It bears a relation to "Real Programmers can write Fortran in any
language", but I hesitate to call it a "corollary".

[ dodges ]

--
Toon Moene - mailto:***@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Harry Conover

2004-01-21 22:59:32 UTC

Post by Richard Maine

Post by Jan C. VorbrÃ¼ggen
For any modern compiler of a 3GL language, not compiling with (the equivalent
of) -fast is grossly negligent.

If he was dealing with embedded software, the original designer may
have had good reason not to turn on the optimizer.

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.

IIRC, Microsoft's "MASM" was an assembler whose optimization exhibited
this defect. Today, no many people use MASM, so I don't know if the
flaw was ever corrected. As a result, many embedded software/firmware
designers today still operate with the optimizer turned off for
"safety", and prefer to optimize their own code.

Franklin's 8051 development suite initially exhibied the same problem,
but given that their target market was entired embedded software
designers, the problem was corrected by the 2nd release of the
product.

Post by Richard Maine
It was a Fortran code, but the major problems didn't have much to
do with the language. If you are sufficiently clueless, you can
manage to express that cluelessness in any language.

Amen to that statement, and suggest that it be etched it in stone.

A skilled programmer can even write in GWBASIC and produce fantastic
results through the clever use of (IIRC) PUT and POKE commands, which
allow the insertion of machine language instructions in the GWBASIC or
the Atari BASIC command stream. (I wonder how many of today's
programmers would be resouceful enough to use of such extreme
techniques to achieve their goals? Heck, for that matter how many have
ever even directly used machine code?)

Harry C.

Alan Balmer

2004-01-21 23:44:45 UTC

Post by Harry Conover
A skilled programmer can even write in GWBASIC and produce fantastic
results through the clever use of (IIRC) PUT and POKE commands, which
allow the insertion of machine language instructions in the GWBASIC or
the Atari BASIC command stream. (I wonder how many of today's
programmers would be resouceful enough to use of such extreme
techniques to achieve their goals?

Programmers tend to be as resourceful as necessary, to the detriment
of the remainder of the code's life cycle.. Fortunately, such
techniques are usually not necessary on today's programming platforms.
Unfortunately, some programmers use them anyway.

Post by Harry Conover
Heck, for that matter how many have
ever even directly used machine code?)

Rarely needed, even in my day. Assembler language is much preferable,
and lots of people still use it. Direct use of machine code is (was)
sometimes useful for debugging and patching.

--
Al Balmer
Balmer Consulting
***@att.net

Jan C. Vorbrüggen

2004-01-22 07:31:00 UTC

Post by Harry Conover
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

Willem

2004-01-22 13:27:51 UTC

)> 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

Jan C. Vorbrüggen

2004-01-22 13:42:21 UTC

Post by Willem
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 ?

Unfortunately, most language's definition of "volatile" is off the mark,
or indeed nobody really knows what it actually _is_ - has this problem
been solved for C99 yet?

As I remarked, you need to do more than just ensuring a store is actually
generated by the compiler - you also need to make sure it's pushed out to
whatever its destination is. Look for "(write) memory barrier", for instance.

Jan

Alan Balmer

2004-01-22 15:43:36 UTC

On Thu, 22 Jan 2004 14:42:21 +0100, Jan C. Vorbrüggen

Unfortunately, most language's definition of "volatile" is off the mark,
or indeed nobody really knows what it actually _is_ - has this problem
been solved for C99 yet?

I don't know what problem you mean, but C has had the volatile keyword
since C89, and it's defined clearly in terms of what the compiler is
allowed to do. I have no idea whether it corresponds to your
definition - you'll have to read the standard and decide for yourself.
As for other languages, if they don't have the capability, they aren't
suitable for the job - use something else.

--
Al Balmer
Balmer Consulting
***@att.net

Nick Maclaren

2004-01-22 17:21:21 UTC

Post by Alan Balmer
On Thu, 22 Jan 2004 14:42:21 +0100, Jan C. Vorbrüggen

Unfortunately, most language's definition of "volatile" is off the mark,
or indeed nobody really knows what it actually _is_ - has this problem
been solved for C99 yet?

You have got it completely wrong. Not merely is it not clearly
defined, there isn't even a consensus among the C standard committee
on what its intent is! You have missed the point when reading the
C standard that volatile has visible semantic effects only under
circumstances where the behaviour is undefined.

Except for the unimportant case of local variables and longjmp,
of course, but that is also soluble without volatile.

Post by Alan Balmer
As for other languages, if they don't have the capability, they aren't
suitable for the job - use something else.

I know of no major language that specifies semantics down to the level
needed for asynchronous signal handling, unfortunately.

Regards,
Nick Maclaren.

CBFalconer

2004-01-22 18:16:47 UTC

Nick Maclaren wrote:
... snip ...

Post by Nick Maclaren
I know of no major language that specifies semantics down to the
level needed for asynchronous signal handling, unfortunately.

Ada.

--
Chuck F (***@yahoo.com) (***@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nick Maclaren

2004-01-22 18:40:36 UTC

Post by CBFalconer
... snip ...

Post by Nick Maclaren
I know of no major language that specifies semantics down to the
level needed for asynchronous signal handling, unfortunately.

Ada.

When I last looked, it didn't, not even remotely. I don't know whether
the designers of that aspect didn't understand the issues, or knew
that they were so foul that they deliberately did not permit them.
There were probably some people in each category :-)

Regards,
Nick Maclaren.

CBFalconer

2004-01-23 01:52:29 UTC

Post by CBFalconer
... snip ...

Post by Nick Maclaren
I know of no major language that specifies semantics down to the
level needed for asynchronous signal handling, unfortunately.

Ada.

Look again. Among other things, it implements monitors. I am
fairly sure the real Ada experts will chime in shortly.

--
Chuck F (***@yahoo.com) (***@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

James Rogers

2004-01-23 04:04:41 UTC

Post by CBFalconer
... snip ...

Post by Nick Maclaren
I know of no major language that specifies semantics down to the
level needed for asynchronous signal handling, unfortunately.

Ada.

Ada does not use the volatile semantics for asynchronous signal handling.
Ada does define a pragma volatile. It is used to force direct writes to
memory. Unfotunately, that is not enough to properly support concurrent
access to a shared memory. A task may be interrupted in the middle of
a read or write, leaving the memory region in an invalid state, while
another task attempts to access the memory region.

Ada provides pragma atomic to specify that the programmer wants all
reads and writes to a memory region to be atomic. Unfortunately, only
data types the size of a word on the execution platform can support
atomic operations.

When handling signals Ada provides a higher level abstraction that
works remarkably well in a concurrent environment.

A procedure of a protected object is associated with a particular
signal. That procedure will be called when the signal is caught by
the Ada program. The procedure will have exclusive access to the
data members of the protected object. That protected object will
also contain an entry. The entry will be called by the signal servicing
task. The task will suspend until the signal is caught.

I believe an example is needed.

-----------------------------------------------------------------------
-- Package Handler
-- Defines the interface for a signal handler
-----------------------------------------------------------------------
with Ada.Interrupts.Names;
use Ada.Interrupts.Names;

package Handler is
protected Int_Handler is
procedure Increment;
entry Wait_For_Interrupt;
pragma Attach_Handler(Increment, Sigint);
private
Counter : Natural := 0;
end Int_Handler;

task Responder is
entry Stop;
end Responder;
end Handler;

-----------------------------------------------------------------------
-- Package Body Handler
-- Defines implementation of the signal handler
-----------------------------------------------------------------------
with Ada.Text_Io;

package body Handler is
protected body Int_Handler is
procedure Increment is
begin
Counter := Counter + 1;
end Increment;
entry Wait_For_Interrupt when Counter > 0 is
begin
Counter := Counter - 1;
end Wait_For_Interrupt;
end Int_Handler;

task body Responder is
Num_Ints : Natural := 0;
begin
loop
select
Int_Handler.Wait_For_Interrupt;
Num_Ints := Num_Ints + 1;
Ada.Text_Io.Put_Line("Handled interrupt number" &
Natural'Image(Num_Ints));
or
delay 0.001;
select
accept Stop;
exit;
or
delay 0.0;
end select;
end select;
end loop;
end Responder;
end Handler;

Every time the signal Sigint is caught the procedure Increment is
executed. Increment simply increments Counter. At the same time we
have the task Responder. Responder calls Wait_For_Interrupt. If
the Counter member of Int_Handler is greater than 0 the task
immediately prints its message and loops back to handle another
interrupt. Wait_For_Interrupt decrements Counter so that each
interrupt is handled only once. If Counter is 0 the Responder task
will suspend. Inside the Responder task the call to Wait_For_Interrupt
is performed conditionally within a select structure. If the 0.001
second delay expires before the interrupt occurs the call to
Wait_For_Interrupt is cancelled and the task checks its Stop
entry to see if some other task has called Stop. If so, the loop
exits and the task terminates. If not, the task immediately
again calls Wait_For_Interrupt.

An example of using this package is the following procedure:

-----------------------------------------------------------------------
-- Procedure Handler_Test
-- This is a program demonstrating interrupt handling
-----------------------------------------------------------------------
with Ada.Text_Io;
with Handler;

procedure Handler_Test is
begin
for Num in 1..20 loop
Ada.Text_Io.Put_Line("Iteration" & Integer'Image(Num));
delay 0.5;
end loop;
Handler.Responder.Stop;
end Handler_Test;

Note that volatile attributes are not used. Instead, the Ada
approach is to use an implementation of a monitor, with the
procedure attached to a specified interrupt.

Jim Rogers

Nick Maclaren

2004-01-23 11:02:46 UTC

Post by James Rogers

Post by Nick Maclaren
I know of no major language that specifies semantics down to the
level needed for asynchronous signal handling, unfortunately.

Ada.

That is getting closer to the real problems. However, the problem of
atomicity does NOT apply just to explicit memory accesses, but to all
primitives in the language - such as I/O calls.

When you get an asynchronous interrupt in the middle of such, you can
delay that until the call completes, suspend the call or abort the call.
In the first case, you can get stuck applications. In the latter, you
have to specify PRECISELY what may be done during the suspension or
after the call is aborted.

And it was the precise specification of which primitives were atomic,
and exactly what the effect of suspending or aborting a non-atomic
primitive, that I remember not finding. But it was a while ago.

Regards,
Nick Maclaren.

James Rogers

2004-01-23 13:49:55 UTC

Post by James Rogers

Post by Nick Maclaren
I know of no major language that specifies semantics down to the
level needed for asynchronous signal handling, unfortunately.

Ada.

That is getting closer to the real problems. However, the problem of
atomicity does NOT apply just to explicit memory accesses, but to all
primitives in the language - such as I/O calls.
When you get an asynchronous interrupt in the middle of such, you can
delay that until the call completes, suspend the call or abort the call.
In the first case, you can get stuck applications. In the latter, you
have to specify PRECISELY what may be done during the suspension or
after the call is aborted.
And it was the precise specification of which primitives were atomic,
and exactly what the effect of suspending or aborting a non-atomic
primitive, that I remember not finding. But it was a while ago.

The problem with asynchronous interrupts is just a special case of
concurrency. Whenever you write a concurrent application, whether
through the use of interrupts, threads, or a combination of both,
you must be able to deal with execution interruption and race
conditions.

Atomicity is not assignable to all memory regions and all devices.
There is simply no way to make a concurrent program run properly if
an I/O operation cannot be interrupted for another thread or an OS/HW
interrupt. Any I/O operation can potentially take an infinite amount
of time. You force serialization around any atomic operation.

The more workable solution is to designate a particular task or thread
to handle the I/O operation. It can then communicate asynchronously with
other tasks in the program through monitor mechansims such as I used in
my previous example. The monitors use locking to effect atomicity and
mutual exclusion. This is generally much more reliable and applicable
to data of all sizes, not just those that can be declared atomic.

The reason you do not find what you are looking for is that you are
looking for the wrong solution to the problem. Ada does not provide
a definition of that wrong solution. It does provide a definition of a
correct solution.

Jim Rogers

Nick Maclaren

2004-01-23 14:12:15 UTC

In article <***@204.127.36.1>,
James Rogers <***@att.net> writes:
|>
|> The problem with asynchronous interrupts is just a special case of
|> concurrency. Whenever you write a concurrent application, whether
|> through the use of interrupts, threads, or a combination of both,
|> you must be able to deal with execution interruption and race
|> conditions.

Yes. I have dismally failed to persuade many people of that, though :-(

|> Atomicity is not assignable to all memory regions and all devices.
|> There is simply no way to make a concurrent program run properly if
|> an I/O operation cannot be interrupted for another thread or an OS/HW
|> interrupt. Any I/O operation can potentially take an infinite amount
|> of time. You force serialization around any atomic operation.

Well, yes, but ....

|> The more workable solution is to designate a particular task or thread
|> to handle the I/O operation. It can then communicate asynchronously with
|> other tasks in the program through monitor mechansims such as I used in
|> my previous example. The monitors use locking to effect atomicity and
|> mutual exclusion. This is generally much more reliable and applicable
|> to data of all sizes, not just those that can be declared atomic.

No, that is not so. It is a partial solution, at best. There are
two major problems with it:

Firstly, you are describing a single-level solution, but it needs to
be applied recursively. For example, an I/O transaction needs its
own thread. If that can issue multiple outstanding transfers, each
of those must have its own. And so on for a modern, multi-layer I/O
system. Not impossible, but very painful and with a large overhead;
and efficiency cannot be completely ignored.

Secondly, there are often circumstances where an application needs
to cancel an I/O operation or connexion. Waiting until it completes
is NOT adequate. In that case, for a robust program, the language
needs to specify precisely what is permitted and what the state of
the objects will be afterwards.

|> The reason you do not find what you are looking for is that you are
|> looking for the wrong solution to the problem. Ada does not provide
|> a definition of that wrong solution. It does provide a definition of a
|> correct solution.

You have descended into religious dogma, I am afraid. I am looking
for any adequate solution to the real problems. While Ada's approach
is at least as viable as any language provides (as far as I know), it
is STILL not a solution to some of the problems that need a solution.

Yes, I have drafted designs for solutions to some problems using the
methods you advocate. In some cases, I have come to the conclusion
that they would help 50% of the time at the cost of doubling the
amount of code and time taken. That isn't a nice balance and, for
many requirements, isn't an acceptable balance.

I believe that there are better solutions, though there can be no
perfect answer.

Regards,
Nick Maclaren.

Jim Rogers

2004-01-23 22:47:48 UTC

Post by Nick Maclaren
Firstly, you are describing a single-level solution, but it needs to
be applied recursively. For example, an I/O transaction needs its
own thread. If that can issue multiple outstanding transfers, each
of those must have its own. And so on for a modern, multi-layer I/O
system. Not impossible, but very painful and with a large overhead;
and efficiency cannot be completely ignored.
Secondly, there are often circumstances where an application needs
to cancel an I/O operation or connexion. Waiting until it completes
is NOT adequate. In that case, for a robust program, the language
needs to specify precisely what is permitted and what the state of
the objects will be afterwards.

I think I understand better what you are talking about.

In my opinion it is pretty much hopeless to expect a language to
define
a solution to this problem. You are at the intersection of language
definition, operating system api, and device drivers. I do not see how
a language can provide a good uniform abstraction for device drivers
written to no particular behavioral standard.

Post by Nick Maclaren
|> The reason you do not find what you are looking for is that you are
|> looking for the wrong solution to the problem. Ada does not provide
|> a definition of that wrong solution. It does provide a definition of a
|> correct solution.
You have descended into religious dogma, I am afraid. I am looking
for any adequate solution to the real problems. While Ada's approach
is at least as viable as any language provides (as far as I know), it
is STILL not a solution to some of the problems that need a solution.

Yes, I may have done so. I am sorry. It was not my intent.

Post by Nick Maclaren
Yes, I have drafted designs for solutions to some problems using the
methods you advocate. In some cases, I have come to the conclusion
that they would help 50% of the time at the cost of doubling the
amount of code and time taken. That isn't a nice balance and, for
many requirements, isn't an acceptable balance.

Monitors and mutex locks do create additional execution overhead
compared to non-locking solutions. Locking solutions have a number
of virtues. However, if their performance does not meet requirements,
one must develop alternate approaches.

The amount of coding required for monitors and mutex locks does
vary somewhat from one language to another. There is always some extra
coding effort compared to some non-locking solutions. I can imagine
some non-locking solutions that require a lot of coding. I suspect
those solutions would be avoided whenever possible.

I find the coding overhead of monitors and mutex solutions to be
minimal when using languages that provide direct syntax for the
creation of such beasts. Your estimate of 50% additional coding
overhead is much more than my personal experience. For instance,
in Java you simply add the "synchronized" keyword to a method or
block definition, then you may also need to add "wait()" and
"notifyAll()" calls in the synchronized block. In Ada, you use
a protected object that implicitly handles all locking and queuing
issues.

Stream of consciousness mode on ---

I was just thinking about your issues of cancellation and
continuation. Ada does provide a feature called Asynchronous
Transfer of Control.

Following is an extract from the Ada Language Reference Manual:

An asynchronous select_statement provides asynchronous transfer of
control upon completion of an entry call or the expiration of a delay.

Syntax

asynchronous_select ::=
select
triggering_alternative
then abort
abortable_part
end select;

triggering_alternative ::= triggering_statement
[sequence_of_statements]

triggering_statement ::= entry_call_statement | delay_statement

abortable_part ::= sequence_of_statements

Dynamic Semantics

For the execution of an asynchronous_select whose
triggering_statement
is an entry_call_statement, the entry_name and actual parameters are
evaluated as for a simple entry call (see 9.5.3), and the entry call
is
issued. If the entry call is queued (or requeued-with-abort), then the
abortable_part is executed. If the entry call is selected immediately,
and never requeued-with-abort, then the abortable_part is never
started.

For the execution of an asynchronous_select whose
triggering_statement
is a delay_statement, the delay_expression is evaluated and the
expiration
time is determined, as for a normal delay_statement. If the expiration
time
has not already passed, the abortable_part is executed.

If the abortable_part completes and is left prior to completion of
the triggering_statement, an attempt to cancel the
triggering_statement is made.
If the attempt to cancel succeeds (see 9.5.3 and 9.6), the
asynchronous_select is complete.
9
If the triggering_statement completes other than due to
cancellation,
the abortable_part is aborted (if started but not yet completed -- see
9.8).
If the triggering_statement completes normally, the optional
sequence_of_statements of the triggering_alternative is executed after
the abortable_part is left.

Examples

Example of a main command loop for a command interpreter:

loop
select
Terminal.Wait_For_Interrupt;
Put_Line("Interrupted");
then abort
-- This will be abandoned upon terminal interrupt
Put_Line("-> ");
Get_Line(Command, Last);
Process_Command(Command(1..Last));
end select;
end loop;

Example of a time-limited calculation:

select
delay 5.0;
Put_Line("Calculation does not converge");
then abort
-- This calculation should finish in 5.0 seconds;
-- if not, it is assumed to diverge.
Horribly_Complicated_Recursive_Function(X, Y);
end select;

I know this does not meet all your needs. I believe it comes
nearer than most languages. I am sure you will correct me if
my belief is incorrect.

Jim Rogers

Nick Maclaren

2004-01-24 12:25:23 UTC

Post by Jim Rogers

Post by Nick Maclaren
Firstly, you are describing a single-level solution, but it needs to
be applied recursively. ...
Secondly, there are often circumstances where an application needs
to cancel an I/O operation or connexion. ...

I think I understand better what you are talking about.
In my opinion it is pretty much hopeless to expect a language to
define
a solution to this problem. You are at the intersection of language
definition, operating system api, and device drivers. I do not see how
a language can provide a good uniform abstraction for device drivers
written to no particular behavioral standard.

No, I am not asking for a language to define a solution to the problem;
I agree that it is impractical, if not actually impossible. Well, the
recursion bit IS soluble, but the cancellation one isn't.

What I am saying is that the language needs to defined PRECISELY what
operations are bounded-time atomic, indefinite-time non-interruptible,
and so on. In the case of an interruption (of ANY type), it needs to
say whether a data value will have either the previous or next value,
an undefined but valid value, or be totally corrupt. And exactly how
far that corruption spreads, which isn't a trivial issue (look at the
value of a pointer to space that has been freed in C).

All of that is possible. It doesn't enable solutions, but it DOES
enable a programmer or program validator to state whether a program
is legal or illegal. At present, that is rarely possible.

Post by Jim Rogers
Monitors and mutex locks do create additional execution overhead
compared to non-locking solutions. Locking solutions have a number
of virtues. However, if their performance does not meet requirements,
one must develop alternate approaches.
The amount of coding required for monitors and mutex locks does
vary somewhat from one language to another. There is always some extra
coding effort compared to some non-locking solutions. I can imagine
some non-locking solutions that require a lot of coding. I suspect
those solutions would be avoided whenever possible.

I didn't make myself clear, I am afraid. I agree that the extra cost
of synchronisation is small, but the cost of making it possible can
be very large. Consider a typical case where different threads have
access to different 'views' of the same object - especially when the
views interleave but do not overlap. You often need a HELL of a lot
more copying to enable threads to be cancellable at synchronisation
points.

When such data division is natural, BOTH in terms of the data structure
AND in terms of the thread structure, you have little trouble. But,
when the data structure and thread structure are very different, it
can be a foul job. This impacts even simple matrix methods, such as
are used in ScaLAPACK.

Post by Jim Rogers
Stream of consciousness mode on ---
I was just thinking about your issues of cancellation and
continuation. Ada does provide a feature called Asynchronous
Transfer of Control.

Yes, but it is primarily the lower level issues I am thinking of,
as well as the problem of cancelling in sections of code that are not
written to be interrupted. And the latter is essential for practical
use, both for the reasons given above and because it is unreasonable
to expect ALL libraries to be written using such methods.

Regards,
Nick Maclaren.

Harry Conover

2004-01-21 22:35:34 UTC

Now that I can believe! :-)

I'm still supporting embedded 8051 packages running on the original
Franklin RTOS, nearly all embedded control systems using the Intel
80X86 family now run VxWorks, with the exception of the 80186. Wind
River is certainly doing something right.

Their VxWorks RTOS package is really slick...I know this because I was
once comissioned to write a RTOS OS for the 80186 similar to VxWorks
(which doesn't support the 80186 in order to provide support for a
legacy PLC controller design. Sadly, the firm quickly lost interest
and cancelled the funding 3-months into the project, just when I was
begining to become really good at rewriting VxWorks 80386 OS code into
80186 code! :-)

I never found out if the mission was scrubbed because of an internal
marketing decision, or because Wind River and its attorneys got wind
(no pun inteded) of the project.

What do/did you think of "Tornado"? Seemed to me that it was equally
as bad as "Starteam", and the neither of these two CM systems came
close to equaling the features provided by the old Unix PWB (for you
newbies, PWB "Programmers Workbench", arguably the original software
configuration management tool).

Harry C.

Theo

2004-01-17 13:34:45 UTC

Post by JavaJunkie
Had it been running Microsoft .NET, the payload would be heavier due to more
memory needed to run Windows, the cost higher due to licensing fees NASA
would have to pay Bill Gates/Microsoft, and by now would be sending back the
"blue screen of death" instead of the martian surface!

You give it too much credit!

Harry Conover

2004-01-21 22:06:56 UTC

Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.

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!)

Java is absolutely useless except when running on a platform already
equipped with an operating system, and many layers of data
communications and application programs, where the top levels include
an operating TCP/IP stack and browser software.

Almost certainly the OS within the rover is a highly optimized
real-time kernel likely programmed in assembler, C, C++ or some other
system implementation langage. (Perhaps even Ada, although that would
be a long-shot.) Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it. Java is
not running the Rover, its real-time operating system is.

My guess is that when you get details of the facts supporting this PR
release, you'll learn that certain Java apps form a portion of the
man-machine interface design employed for the entry of command
sequences here on earth, since Java is capable of simpllifying the
design of this type of software over what could otherwise be
programmed using xlib, C, C++ or even (gasp) assembly language, since
the programming of a control entry MMI is today not exactly rocket
science (no pun intended). (Heck, you could probably even use Visual
Basic for the purpose, if really desperate! Back in the early days of
surveilance satellites, we even programmed the ground based command
interpreters for the K-series birds using Fortran, and they were both
trivial to program and functioned perfectly.)

Also, at last count the foundations of the Internet rested heavily on
C/C++/Assembler implementations running on Unix platforms, however
this may or may not have changed over the years. (At last count, the
thousands of different routines supporting operation of the Internet
involved the use of nearly as many different programming tools...since
so long as they all result in the production of really tight, robust,
executable machine code, the choice of programming language really
doesn't matter.)

When a firm intentionally confuses application programming tools such
as Java with real-time OS implementation methodoloy, in my mind they
both risk and deserve justifiable ridicule. I don't believe that Sun
intended to create such confusion in their publicity release, however
a few Java enthusiasts do seem bent on misrepresentation of Java's
capabilities, potentially at Sun's credibility expense.

Harry C.

Alan Balmer

2004-01-21 23:01:30 UTC

You're about four days late with this observation ;-) Folks who
actually read the referenced article, "Java runs remote-controlled
Mars rover", learned that while a Java program "runs" a simulated
rover, here on earth, and is a very useful tool for mission planning,
it does not run *on* the rover, or directly control it. Read the
article.

You can get the software at http://mars.telascience.org/

--
Al Balmer
Balmer Consulting
***@att.net

Michael N. Christoff

2004-01-22 00:46:59 UTC

Mike, I have no facts to support this, but my guess is that that the
PR blurb you post is little more than a bit of marketing spin whose
quotes are being read out of context by a few Java enthusiasts.
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!)
Java is absolutely useless except when running on a platform already
equipped with an operating system, and many layers of data
communications and application programs, where the top levels include
an operating TCP/IP stack and browser software.
Almost certainly the OS within the rover is a highly optimized
real-time kernel likely programmed in assembler, C, C++ or some other
system implementation langage. (Perhaps even Ada, although that would
be a long-shot.) Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it. Java is
not running the Rover, its real-time operating system is.
My guess is that when you get details of the facts supporting this PR
release, you'll learn that certain Java apps form a portion of the
man-machine interface design employed for the entry of command
sequences here on earth, since Java is capable of simpllifying the
design of this type of software over what could otherwise be
programmed using xlib, C, C++ or even (gasp) assembly language, since
the programming of a control entry MMI is today not exactly rocket
science (no pun intended). (Heck, you could probably even use Visual
Basic for the purpose, if really desperate! Back in the early days of
surveilance satellites, we even programmed the ground based command
interpreters for the K-series birds using Fortran, and they were both
trivial to program and functioned perfectly.)
Also, at last count the foundations of the Internet rested heavily on
C/C++/Assembler implementations running on Unix platforms, however
this may or may not have changed over the years. (At last count, the
thousands of different routines supporting operation of the Internet
involved the use of nearly as many different programming tools...since
so long as they all result in the production of really tight, robust,
executable machine code, the choice of programming language really
doesn't matter.)
When a firm intentionally confuses application programming tools such
as Java with real-time OS implementation methodoloy, in my mind they
both risk and deserve justifiable ridicule. I don't believe that Sun
intended to create such confusion in their publicity release, however
a few Java enthusiasts do seem bent on misrepresentation of Java's
capabilities, potentially at Sun's credibility expense.

a) the article never said that Java was on the rover itself. b) Java is
more than a language, it is a platform. c) the fact that Java needs an
underlying OS has never been disputed by anyone. The idea is for Java to be
portable to other _already developed_ platforms. It would not be very
portable if you had to dual boot into a Java OS to run Java apps. 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. (note: many many people laughed at the
idea that something as small as a cell-phone could run any VM-based
language. Java on top of VM on top of embedded OS seemed way too bulky to
ever be practical. But Moore's law apparently does not apply only to
desktops, but even embedded devices). Will a real-time Java have all the
features of regular Java? Doubtful. ie: automatic garbage collection may
not be possible.

l8r, Mike N. Christoff

Michael N. Christoff

2004-01-22 00:52:18 UTC

Post by Harry Conover
Java is certainly not a member of this tight-knit
club of system implementation languages, and I simply cannot picture
anyone even attempting to implement a real-time OS using it.

As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.

I posted this already in another thread.

Jim Sculley wrote:
<quote>
In any event this entire discussion has ignored the Realtime
Specification for Java, implementations of which are being used in
mission critical apps, such as control systems for a future Mars rover:

http://www.opengroup.org/rtforum/uploads/40/2930/OpenGroup_Golden_Gate_May01
-v05.pdf

Jim S.
</quote>

l8r, Mike N. Christoff

Harry Conover

2004-01-24 03:29:42 UTC

As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.

No, what you actually posted was (unless attrition of this to you was
in error):

"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a

Post by Michael N. Christoff
universal operating system for Internet applications, gave NASA a low-cost
and easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life."

Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.

Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.

Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.

Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.

I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.

I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and
life."

The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".

Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.

Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.

Rant complete! ... -.-

Harry C.

Michael N. Christoff

2004-01-24 10:27:20 UTC

As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.

No, what you actually posted was (unless attrition of this to you was
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a

Running Java code with deterministic time constraint on operations
could be conceptually employed to construct a real-time OS, but in
reality could not be done simply due to the fact that the Java
implementation is so layered and ridiculously bloated, that it would
be practically incapable of meeting the microsecond and millisecond
timing constraints typically imposed on the deep end of a real-time
operating systems.
Certainly Java is capable of non real-time task such as the timely
update of a wall clock time display, or the issuance of coontrol
sequences based on clock time, but it depends of the capabilities of
some RTOS to provide the time-of-day services on which it feed to
provide these capabilities.
Due to it's very high-order application focus (that it, consists of
application level functions, not machine oriented instructions), I
really cannot imagine of a Java implementation that would lend itself
to RTOS applications, whether a VM implementation or not.
Then too, I don't believe that this is what you are trying to say, and
I believe the confusion is cause by someone erroneously attributed a
quote from the Sun PR blurb to you.
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
I have no problem with Java, its capabilities, or its applications,
however I do strenuously object to the statement that: "Java, the
software developed by Sun Microsystems in the mid-1990s as universal
operating system for Internet applications, gave NASA a low-cost and
easy-to-use option for running Spirit, the robotic rover that rolled
onto the planet's surface on Thursday in search of signs of water and life."
The simple facts of life are that Java was not developed as a
"universal operating system for Internet applications" nor is a
real-time operating system "option for running Spirit".
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.
Rant complete! ... -.-
Harry C.

Michael N. Christoff

2004-01-24 10:37:25 UTC

As I mentioned, you would not implement the OS in Java, but would implement
a VM for the OS that allows one to run Java code with deterministic time
contraints on operations.

No, what you actually posted was (unless attrition of this to you was
"> > Java, the software developed by Sun Microsystems in the mid-1990s
as a

I just copied that from the article to introduce the link, it is not my
personal opinion.

[argument based on this snipped]

Post by Harry Conover
I suspect that tranlated to my language, what you're telling us is
that one could employ a Java implementation running on top of the
environment created by a real-time operating system, something that is
routinely done.
Spirit's applications level software could well be Java, or Fortran,
Basic, Jovial, Lisp, Forth (Ghod Forbid), or just about any HOL. My
point is that you can damn't well bet that the RTOS that directly
controls (both the good and now the bad on Spirit) is very likely
programmed in a language providing direct machine instruction level
control of its processor, likely C, C++, or assemly langage just as is
the embedded bios in your computer, RAID server, or network
controller.

Perhaps in your group, some messages from the thread are being lost, but the
fact that Java is (almost certainly) not on the rover has been mentioned
numerous times already by many different people.

Post by Harry Conover
Fact is, the controller aboard Spirit is functioning as simply a
glorified PLC, and likely has very similar embedded firmware to that
of earthborne PLCs. Why wouldn't JPL copy this model, 90% of man's
controller experience is using PLCs.

Well it depends. Is the new technology easy to use, inexpensive, and does
it offer useful capabilities and features PLCs do not? These are all
factors that may make changing to a new technology, as tried and true as the
older one may be, a good idea.

l8r, Mike N. Christoff

Jan C. Vorbrüggen

2004-01-22 07:37:11 UTC

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

Harry Conover

2004-01-22 17:47:22 UTC

Jan C. Vorbrüggen <***@mediasec.de> wrote in message news:<***@mediasec.de>...

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

2004-01-22 21:30:29 UTC

Post by 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.

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

Richard Heathfield

2004-01-22 06:05:38 UTC

Post by Harry Conover
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!)

Send them over. I could do with the chip (and the RAM). Feel free to
chuckle, whilst I fetch my screwdriver. :-)

Rod Davison

2004-01-22 13:32:55 UTC

<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.

--
.................................................
99 percent of lawyers give the rest a bad name.

Rod Davison - Critical Knowledge Systems Inc.

Tony Hill

2004-01-23 06:58:14 UTC

On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"

Post by Rod Davison
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.

-------------
Tony Hill
hilla <underscore> 20 <at> yahoo <dot> ca

Joe "Nuke Me Xemu" Foster

2004-01-23 07:18:20 UTC

Post by Tony Hill
On Thu, 22 Jan 2004 13:32:55 GMT, "Rod Davison"

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!

--
Joe Foster <mailto:jlfoster%40znet.com> DC8s in Spaace: <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

David Gay

2004-01-22 16:49:52 UTC

Post by Harry Conover
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.

--
David Gay
***@acm.org

Michael N. Christoff

2004-01-22 21:57:42 UTC

"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

2004-01-22 22:51:59 UTC

Post by 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

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

--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

Michael N. Christoff

2004-01-22 23:02:18 UTC

Post by Joe "Nuke Me Xemu" Foster

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

2004-01-22 23:21:23 UTC

"Joe "Nuke Me Xemu" Foster" <***@bftsi0.UUCP> wrote in message news:***@news-1.nethere.net...
| "Michael N. Christoff" <***@sympatico.caREMOVETHIS> wrote in
message <news:LJXPb.17371$***@news20.bellglobal.com>...
|
| > "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? ;-)

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

Joe "Nuke Me Xemu" Foster

2004-01-23 02:56:55 UTC

Post by 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 is trying to shove through
the ECMA. Apparently nothing is safe from the "embrace and extend"
standards pollution and proprietarization strategy.

Post by Andrew Thompson
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.

--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

Andrew Thompson

2004-01-23 04:51:26 UTC

"Joe "Nuke Me Xemu" Foster" <***@bftsi0.UUCP> wrote in message
| "Andrew Thompson" <***@bigNOSPAMpond.com> wrote in message
| > "Joe "Nuke Me Xemu" Foster" <***@bftsi0.UUCP> wrote in message
|
| > | 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. ;-)

--
Andrew Thompson
* http://www.PhySci.org/ PhySci software suite
* http://www.1point1C.org/ 1.1C - Superluminal!
* http://www.AThompson.info/andrew/ personal site

2004-01-23 14:21:52 UTC

Post by Andrew Thompson
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. ;-)

you write it wrong:
MicrobaStard is right!
--

____________

http://reader.imagero.com the best java image reader.

Andrew Thompson

2004-01-23 23:04:32 UTC

"ak"
..
| > Windoze and MicroBastard ..
..
| MicrobaStard is right!

LOL! Yep, that fits ;-)

Rick Osborn

2004-01-23 05:52:20 UTC

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

Post by Andrew Thompson
|
| > "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? ;-)

Joe "Nuke Me Xemu" Foster

2004-01-23 06:04:09 UTC

Post by Rick Osborn
I think they should turn it off and turn it on again.

They need to reinstall Winblows...

--
Joe Foster <mailto:jlfoster%40znet.com> Sacrament R2-45 <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

Theo

2004-01-23 14:01:20 UTC

Post by Joe "Nuke Me Xemu" Foster

Post by Rick Osborn
I think they should turn it off and turn it on again.

They need to reinstall Winblows...

or WhimClose

Torben Ægidius Mogensen

2004-01-23 08:10:23 UTC

Post by Rick Osborn
I think they should turn it off and turn it on again.

It may be a bit hard to reach the on/off switch.

If I was to make such a vehicle, I woul dmake sure to allow it to be
rebooted by remote control even when the computer is in some undefined
state, e.g., by having a simple circuit listening to the incoming
signals and when a specific sequence occurs, reboot the main computer.

Torben

Uncle Al

2004-01-23 01:24:19 UTC

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.

--
Uncle Al
http://www.mazepath.com/uncleal/
(Toxic URL! Unsafe for children and most mammals)
"Quis custodiet ipsos custodes?" The Net!

Alan Balmer

2004-01-23 18:10:16 UTC

Post by Uncle Al

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

Since they're getting good signal, but meaningless data, the antenna
is not likely to be the problem, is it?

Post by Uncle Al
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.

I wouldn't "presume" anything without considerably more data.
Actually, I would - I presume that NASA has people working on the
problem that are at least as competent as you are ;-)

--
Al Balmer
Balmer Consulting
***@att.net

Joe "Nuke Me Xemu" Foster

2004-01-23 07:01:34 UTC

"This behavior is by design."

--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

Michael N. Christoff

2004-01-24 02:09:02 UTC

Thanks to Mickey Segal for this link

NASA Makes Contact With Mars Rover
http://news4colorado.com/nationworld/topstories_story_023135646.html

l8r, Mike N. Christoff

Randy Howard

2004-01-24 05:18:56 UTC

Post by Michael N. Christoff
Thanks to Mickey Segal for this link
NASA Makes Contact With Mars Rover
http://news4colorado.com/nationworld/topstories_story_023135646.html

Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)

--
Randy Howard
2reply remove FOOBAR

Matt Timmermans

2004-01-24 16:36:35 UTC

Post by Randy Howard
Ah, the Martians are just playing with us, sending a few brief seconds
on data to make us believe it's still all by itself. Next thing you
know, they'll rig it to send back data proving there is no actual
life on mars. :-)

There is no life on Mars. They all live inside.

EventHelix.com

2004-01-24 15:45:20 UTC

It seems to be a software problem. The rover is rebooting frequently.

Who says there is no life on Mars? ... We have bugs.

In any case what the rover has accomplished thus far is a technical
feat that we should be proud of.

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - System Architecture Design CASE Tool

Alf P. Steinbach

2004-01-24 17:18:35 UTC