Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 5 May 1999 09:51:09 GMT
|
Viewed:
|
1065 times
|
| |
|
|
In lugnet.robotics, lego-robotics@crynwr.com (John A. Tamplin) writes:
> On Tue, 4 May 1999, Sren Hilmer wrote:
>
> > I say Java is the way to go, actually I am planning to do a JVM for the RCX.
> > The JVM is not necessarily complex, It is possible to do a subset, SUN • already
> > does that with the JavaCard specification (that is Java running on • smartcards).
> > This specification rules out things like floats, ints, Strings, Threads,
> > garbage collection, ...
> > some of them we probably need to put back in like threads (and maybe gc).
>
> JavaCard is highly specialized to a SmartCard application. As far as I know,
> the only way to communicate with a JavaCard interpreter is through the ISO
> APDU mechanism. You also don't have computation running in the background,
> since applets only respond to select and process methods.
That is right, but this is mainly enforced by the class library, which
offcourse will have to be way different for the RCX. What I was getting at was
that we do not need to implement the whole java bytecode instruction set, but
could do with a subset. And yes there also are no threads in JavaCard, which we
obviously need.
> > And like in the JavaCard specification some of the stuff that comprise the • JVM
> > does not need to run on the target computer (RCX in our case), the bytecode
> > verifier and the resolver can be run on the computer which downloads the
> > classes to the target (the specification does not require dynamic class • loading
> > either).
>
> EmbeddedJava doesn't require dynamic class loading, but if you do have a
> way of loading classes the bytecode verifier must be present. In JavaCard,
> there is an additional step of verifying the bytecode is a JavaCard subset
> and compressing it.
Yep, that was what I was talking about. In JavaCard they have efectively split
the verification/resolving/compression of the classes away from the executing
device (the smartcard). I think a similar approach could be usefull for the RCX
environment.
> > I have been using five different implementations of the JavaCard • specification
> > by now, and they all seems to work really well.
>
> Which ones are these? I am using the JC2.0 which is implemented by the
> iButton with Java.
I have been using:
a)JavaCard 1.0 implemented on Schlumberger Cyberflex 8K cards.
b)JavaCard 2.0 implemented on the iButton
c)JavaCard 2.0 implemented on Gemplus GemXpresso card
d)JavaCard 2.0 implemented on DeLaRue GalactIC card
e)JavaCard 2.0 SUN ref. implementation (maybe this one doesn't count)
The iButton and the GemXpresso is by far the most sofisticated environments
,iButton has a garbage collector and GemXpresso has a 32 bit RISC processor
supporting 32 bit int's and a way to encode APDU's automatically into function
calls. Offcourse these are proprietary features which you can only use if you
know you do not need to move to another card.
> 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...
|
| (...) You could certainly throw some sort of "unsupported" exception when you see a d* bytecode, but the biggest issues aren't implementing 64-bit ints and floats but rather garbage collection and threading. JC doesn't require either, but some (...) (25 years ago, 5-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Something else is needed, I think...
|
| (...) JavaCard is highly specialized to a SmartCard application. As far as I know, the only way to communicate with a JavaCard interpreter is through the ISO APDU mechanism. You also don't have computation running in the background, since applets (...) (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
|
|
|
|
