Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 May 1999 19:04:56 GMT
|
Original-From:
|
John A. Tamplin <jat@liveonthenet.com[Spamless]>
|
Viewed:
|
1226 times
|
| |
|
|
On Tue, 4 May 1999, Mark Tarrabain wrote:
> Java is a very good language, but *NOT* a very good choice of language for robot
> control. Java's greatest strength is its portability, but portable programs in
> hardware like the RCX, are not likely to accomplish much. (Have you ever tried to
> write a device driver in Java? Sorta defeats the point to writing in Java,
> doesn't it?) Further, Java bytecode is many many many times more complicated than
> something else which just controls the RCX needs to be. The key advantage to
> making a JVM for the RCX seems to be that there would be no need to design a new
> bytecode set, and especially that there would be no need to develop compilers for
> it because there already exists an abundance of them for all sorts of platforms.
Don't forget writing the bytecode interpreter. With JVM, we just have to
port that. Writing a bytecode interpreter that is fast, general purpose,
supports multithreading & synchronization etc. is no small task.
> I believe that the people who think that this makes implementing a JVM for the RCX
> worthwhile are either under the impression that java is practical for
> device-dependent code, or they believe that writing a compiler is too hard.
Java would not be used for device-dependent code. The low-level
interface to the hardware/OS would be written in C and access through
native methods, just as running JVM on a Unix host.
The issue isn't whether doing all these things is hard -- the issue is if
it is easier to port someone else's work rather than reinvent the wheel why
do the work again? Not to mention the wide variety of tools and expertise
which we could never duplicate.
> The former is defintely not true. As for the second, well... I've had experience
> writing compilers and interpreters, and while I'd say that it's certainly a
> challenging task, it's actually not that difficult to do when one has a good
> knowledge of the target code, and if the source code language specification is
> consistent and not overflowing with exceptions. I've found it to be more tedious
> than difficult, actually. What *IS* hard is designing a virtual machine (bytecode
> interpreter) in such a way that programs running under it can do pretty much
> anything that is computationally possible as well as being able to control every
> aspect of the hardware in an absolutely minimal set of instructions, while at the
> same time, being complex enough to not require lengthy sequences of instructions to
> perform most relatively simple tasks. A minimal instruction set is required so
> that the interpreter does not take up space that would otherwise be useful for
> program and code storage, and a moderately complex set is required because with too
> simple an instruction set, an instruction sequence to do even the most simple
> things would be dozens, hundreds, or sometimes even thousands of instructions long,
> thereby again, reducing the amount of useful code that you can fit within a finite
> amount of space. This balancing act is one of the greatest challenges to robust
> instructiion set design. I can appreciate the tendency for some people to simply
> throw up their hands and surrender to the idea that we should use a pre-designed
> bytecode set.
I'm not saying it is too hard to do, I am suggesting that perhaps it has
already been done and therefore there is no need to reinvent the wheel.
> Nevertheless, I would maintain that in spite of the difficulty, it would still be a
> worthwhile project to undertake. The RCX is a pretty cool piece of hardware, in
> spite of its physical limitations. A more robust programming environment for it
> that could come about through a more versatile bytecode set would open up a world
> of new possibilities to people who may not have the technical expertise to use
> LegOS (or find it too cumbersome), but still find the limitations of the standard
> firmware too restrictive. Such people, I would expect, are quite distinctly in the
> majority.
I have no idea what percentage of the people on this list are "CS geeks" that
want to play with it because it is a cool computer toy. Personally, the
idea of developing the OS/etc is at least as interesting to me as building
real robots. It isn't interesting to me at all to build a robot which drives
around and follows a line -- for me to be interested in it, I want something
more challenging. For me to spend my limited spare time on a project, it
has to be something that interests me personally. If other people also find
it interesting or useful, that is great but it isn't my motivation for
doing it.
John A. Tamplin Traveller Information Services
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 1 Reply:
 | | Re: Something else is needed, I think...
|
| (...) ??? I think you are making a new interpreter sound harder than it really is. The standard firmware might not be incredibly fast, but it certainly supports multithreading, and synchronization wouldn't be hard to add. The only challenging thing (...) (25 years ago, 4-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Something else is needed, I think...
|
| Java is a very good language, but *NOT* a very good choice of language for robot control. Java's greatest strength is its portability, but portable programs in hardware like the RCX, are not likely to accomplish much. (Have you ever tried to write a (...) (25 years ago, 4-May-99, to lugnet.robotics)
|
67 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
