Subject:
|
Re: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 3 May 1999 23:41:31 GMT
|
Viewed:
|
1142 times
|
| |
|
|
John A. Tamplin <jat@liveonthenet.com> wrote:
> The things I like about using JVM (in no particular order):
> ===========================================================
> 1) huge variety of development tools and expertise on many platforms
> 2) compact bytecode
> 3) full-featured support for objects, threading and exceptions
> 4) compiler and interpreter do strict static error checking, interpreter
> does strict dynamic error checking
> 5) JVM is all the interface required to the OS (ie, in C you have libraries
> to do threading, you can have direct access to the hardware, etc)
> 6) portability (specifically it would be easy to write RCX emulation classes
> and run that on any JVM). If it is designed right, the same user code
> should run on any future upgrade of the RCX.
>
> Things I dislike
> ================
> 1) relying on garbage collection on a memory-constrained device
> 2) licensing issues requiring that it implement the full JVM spec
So this is a nice start at least.
Regarding things you like, I'm going to ignore 1) and 6) because they are
not features of byte code, they are features of Java; you either use the
JVM and you get them, or you do not use the JVM and you do not get them.
There's not much more to say about them than that.
Regarding 2), this is a given, everybody wants the byte code to be
compact. Can you shed any light into how Java is made compact? Is it
something non-obvious and different from the standard byte code, and if so,
how is it different?
Regarding 3), these are nice features. With regards to threading, how does
the JVM support this feature? How is it exposed in the byte code? I am
particularly interested what the JVM thinks is the state associated with a
single thread (e.g. a stack, a PC, etc.).
Regarding 4), this is a nice goal. I think it's straightforward in
principle to understand.
Regarding 5), I agree with hiding all OS/hardware issues in the virtual
machine. The JVM does this, the standard byte code does this, and I think
everybody will agree that any new byte code should do this.
You dislikes are noted.
-Kekoa
|
|
Message has 3 Replies:
 | | Re: Something else is needed, I think...
|
| (...) For reference, the JVM specification is available online at this URL: (URL) are several features that promote compactness: 1) it is a stack-based bytecode. Operands are pushed onto the stack, a bytecode is executed, and results are pushed onto (...) (25 years ago, 4-May-99, to lugnet.robotics)
| | | Re: Something else is needed, I think...
|
| Stephen's view: -> We want something higher level than FORTH or C so that it will be usable by *everyone*. We also want something higher level than NQC so it will be *usable* by everyone. In short, for semantic level we'd like something that puts (...) (25 years ago, 4-May-99, to lugnet.robotics)
| | | Re: Something else is needed, I think...
|
| (...) classes (...) Yes but in regard to 1) we do not have to implement a compiler, they arer already there, all we need is the VM. (...) There is a stack and a PC. (...) No way, OS/hardware specific stuff should be in the RCX specific (...) (25 years ago, 4-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Something else is needed, I think...
|
| (...) I guess it depends on what you want in your firmware. I have been working on my own object-oriented kernel, and I have written an object-oriented kernel for an embedded I/O controller before, and it is a big job. That is just the OS, not (...) (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
|
|
|
|
