Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 May 1999 20:27:29 GMT
|
Original-From:
|
John A. Tamplin <JAT@LIVEONTHENET.COMsaynotospam>
|
Viewed:
|
1650 times
|
| |
|
|
On Tue, 4 May 1999, Kekoa Proudfoot wrote:
> 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 to add, mainly because it requires forethought, will
> be variable support. And the majority of the work will not be adding
> better variable support but instead duplicating the functionality of the
> current firmware, for which we have pseudocode to possibly use as a guide
> but no source at this time.
I think the basic issue here is we have different ideas in what we want in
this interpreted language. You seem to want something closer to the current
bytecode, while I want something closer to Java/C++. Certainly if you lower
the requirements for the direct language support in the bytecode the
interpreter becomes more and more simple.
> I (still) think porting the JVM and making it usable is a harder task than
> bringing up a custom, RCX-specific byte code interpreter. If you (you
> being anybody reading this who disagrees with me) think you have the
> knowledge and the capability to port the JVM and hack it to interface
> nicely with the RCX, I urge you to prove me wrong. The proof is in the
> pudding, I'll believe it when I see it, the devil is in the details: they
> all apply here.
The primary concerns I have with the feasibility of porting JVM are the
memory required for the interpreter and the OS facilities required
(specifically memory managment and threading). With an appropriate
subset, the memory should not be an issue -- JavaCard 2.0 runs on an
iButton smaller than a stack of 4 dimes which contains 32k ROM and 6k RAM,
while supporting 1024-bit cryptography functions and garbage collection.
Someone else posted a reference to a port to the 68HC11 which fits in
6.5k, and the H8 should be easier. Given the size of compiled Java code,
having 5-6k free after the OS and JVM should be more than enough.
I don't think any of the current OS replacements out there are capable of
running JVM, which is the biggest holdup.
I am playing around with just compiling the EmbeddedJava runtime for H8 to
get a base idea of how much storage will be required. If it is too large,
class loading and bytecode verification can be moved to the host. I'll
post here when I have more answers.
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 is in Reply To:
 | | 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 (...) (26 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
