Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 3 May 1999 19:00:22 GMT
|
Original-From:
|
John A. Tamplin <jat@liveonthenet.com&SayNoToSpam&>
|
Viewed:
|
1057 times
|
| |
|
|
On Mon, 3 May 1999, Kekoa Proudfoot wrote:
> I think new firmware is a good way to go. I would vote for a completely
> new byte code, perhaps similar in spirit to the original, but designed
> fresh from the ground up. There is no source for the current firmware,
> although there is pseudocode for some of it, so rewriting the firmware from
> scratch is somewhat inevitable already.
>
> If somebody wants to propose a new byte code and machine model (preferably,
> the compiler writer), I might be able to assist in the coding of new
> firmware, having all the information for writing new firmware here at my
> fingertips.
If you really want to design a new bytecode that is completely flexible,
I suggest using the millions of manhours put into the Java Virtual Machine
would be worthwhile. I looked at the idea of porting JVM to the RCX
briefly before, but decided it would be too much work for me. If there
were a large number of competent programmers working on it, it might be
doable.
Here are the problems I see with this approach:
1) Implementing all of JVM is a big project. If you don't implement all
of it, you can't call it Java and you can't redistribute it. There
are JVM-subsets which are officially endorsed, but I have only looked
at JavaCard (I have a Dallas Semiconductor iButton which runs the JCRE).
It is possible that EmbeddedJava or PersonalJava may be a more
appropriate virtual machine to implement, but JavaCard is probably too
restricted to do anything useful and the API is quite specialized for
SmartCard applications.
2) Java requires fairly flexible threads in the underlying OS. From what
I remember of LegOS, it would not be suitable for Java threads.
3) Full Java requires 64-bit integers and 64-bit floats, which H8 gcc does
not support. The JVM port could probably handle that in software, but
it would most definitely be a lot of work changing the reference JVM
implementation.
4) Memory requirements -- the Java .class files themselves are fairly
compact but the JVM and all the native methods are quite large. Since
we wouldn't need awt, JFC, and some of the other large components, it
might fit but it would still eat up a large portion of available RAM.
Garbage collection would be more important and perhaps problematic with
the restricted memory available.
In addition to the JVM, we would have to design packages to interface with
the RCX hardware. We could also implement host versions of these packages
which emulate the RCX hardware so you can test applets (LegoLets?) on a
development system before downloading to the RCX.
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...
|
| (...) My thoughts on the JVM: - too complicated for what we need or want - no direct support for interfacing with the RCX I envision the new byte code being specific to the RCX, and as simple as possible to get the job done, which is the exact (...) (25 years ago, 3-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Something else is needed, I think...
|
| (...) I think new firmware is a good way to go. I would vote for a completely new byte code, perhaps similar in spirit to the original, but designed fresh from the ground up. There is no source for the current firmware, although there is pseudocode (...) (25 years ago, 3-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
|
|
|
|
