| |
I think that what may actually be the best thing for the RCX in
terms of a new bytecode interpreter is one which is virtually a plug-in
replacement for the old one. I've been doing some extensive mulling
over the RCX internals documentation so generously provided by Kekoa,
and I would like to comment on some observations I've made and
conclusions that I've drawn.
There appear to be 193 opcodes in the existing interpreter. This
means that there are 63 unused opcodes for possible instructions. This
should be more than enough to add any extra opcodes necessary to
transcend the limitations while still being compatible with the older
bytecode.
One of the first limitations to be overcome should be the 8
subroutine limit. At least one new instruction should be added which
allows the specification of a 16 bit function address, making available
memory the restrictive aspect rather than merely subroutine count.
The existing system has 32 global variables. It seems to me that an
enhanced interpreter that did not share this limitation could still
remain completely compatible with the existing one (at the bytecode
level) if instead of variables, these are simply considered to be
registers. This way, the only instructions which need to be added to
transcend the 32 variable limit would be the few necessary to move data
between these registers and global or stack memory. Almost all other
computations can be presumed to operate just with registers, and most of
the other instructions would not have to be modified in what they could
do.
I do not believe that a compatible bytecode interpreter can feasibly
have any floating point routines built into it. Fixed point would need
to be used at the source code level. It's not that difficult to, at the
source code level, use everything multiplied by some constant factor
anyways. This also gives the flexibility of the user being able to use
whatever precision they decide is appropriate for their particular
application.
For issues of compatibility, of course, the 32 registers
("variables") must remain global to all threads. I personally don't
particularly care for this, however, and would offer the suggestion that
there be a set of registers ("variables") numbered above 32, which are
local to each task. This should be do-able because to the best of my
knowledge, an entire byte is dedicated to specifying which variable to
work with anyways, rather than just 5 bits. The number of such
registers should be reasonable but not wasteful -- I would suggest 8 as
a minimum and 32 as an absolute maximum. The presence of such registers
*IMMENSELY* simplifies the job of writing compilers that can produce
thread-safe code. (In fact, in bytecode compiled from high level
languages, you might never actually see any reference to any of the
older variables at all!)
|
|
| |
On Thu, 6 May 1999, Mark Tarrabain wrote:
> I think that what may actually be the best thing for the RCX in
> terms of a new bytecode interpreter is one which is virtually a plug-in
> replacement for the old one. I've been doing some extensive mulling
<snip>
Mark and John's messages this morning look like the beginnings of
two separate developments for the RCX, both of which have the potential to
satisfy the needs of many who are dissatisfied with the current firmware.
Hopefully both ideas will be successful - and if they are, then they will
be hugely useful.
My current wish-list and computing skills place me firmly in the "add a
few opcodes to the existing firmware" camp - and I'm extremely willing to
assist in the development effort of such an add-on. I suggest that a small
group should get together (off the list) and come up with a definite
specification, which we could then implement. Would someone like to
volunteer to lead the effort? (Don't look at me - I still have to learn a
lot about the H8 and install a compiler!)
If a similar group is going to try JVM, then I'd like to wish them every
success :-)
Stuart
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
At 13:32 06-05-1999 Thursday , you wrote:
> On Thu, 6 May 1999, Mark Tarrabain wrote:
>
> > I think that what may actually be the best thing for the RCX in
> > terms of a new bytecode interpreter is one which is virtually a plug-in
> > replacement for the old one. I've been doing some extensive mulling
> <snip>
>
> Mark and John's messages this morning look like the beginnings of
> two separate developments for the RCX, both of which have the potential to
> satisfy the needs of many who are dissatisfied with the current firmware.
> Hopefully both ideas will be successful - and if they are, then they will
> be hugely useful.
>
> My current wish-list and computing skills place me firmly in the "add a
> few opcodes to the existing firmware" camp - and I'm extremely willing to
> assist in the development effort of such an add-on. I suggest that a small
> group should get together (off the list) and come up with a definite
> specification, which we could then implement. Would someone like to
> volunteer to lead the effort? (Don't look at me - I still have to learn a
> lot about the H8 and install a compiler!)
>
> If a similar group is going to try JVM, then I'd like to wish them every
> success :-)
I was wondering if any of these projects is thinking in providing enough flexibility that would make possible for anyone smoothly integrate new sensors with the currently supported ones? (Like Dennis Clark's RCX IRPD?)
Sorry to return to this, but any is going to provide some connection to the PC with some library, or even remote debugging capabilities?
Sorry to insist, but my latest projects are involving a lot of processing power and memory lately and I need the help of a PC...
Laurentino Martins
[mailto:lau@mail.telepac.pt]
[http://www.terravista.pt/Enseada/2808/]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
"S. Crawshaw" wrote:
> On Thu, 6 May 1999, Mark Tarrabain wrote:
>
> > I think that what may actually be the best thing for the RCX in
> > terms of a new bytecode interpreter is one which is virtually a plug-in
> > replacement for the old one. I've been doing some extensive mulling
> <snip>
>
> Mark and John's messages this morning look like the beginnings of
> two separate developments for the RCX, both of which have the potential to
> satisfy the needs of many who are dissatisfied with the current firmware.
> Hopefully both ideas will be successful - and if they are, then they will
> be hugely useful.
>
> My current wish-list and computing skills place me firmly in the "add a
> few opcodes to the existing firmware" camp - and I'm extremely willing to
> assist in the development effort of such an add-on. I suggest that a small
> group should get together (off the list) and come up with a definite
> specification, which we could then implement. Would someone like to
> volunteer to lead the effort? (Don't look at me - I still have to learn a
> lot about the H8 and install a compiler!)
My request to both groups is: don't go 'off-list' until you have a feature spec
that was formed with feedback from the whole list. It would be a shame for you
to finish development of a tool that no one else uses.
-Wes
|
|
| |
On Thu, 6 May 1999, Laurentino Martins wrote:
> I was wondering if any of these projects is thinking in providing enough
> flexibility that would make possible for anyone smoothly integrate new
> sensors with the currently supported ones? (Like Dennis Clark's RCX IRPD?)
Absolutely. What I have in mind is that the basic level of access is to
the raw sensor value of the A/D converter and whether it is active or
passive. The interpretation of that value would be done by other classes.
For example, I would like to have a TouchSensor class that works just fine
using the standard Lego sensor on an input port all to itself. I would like
to have a MultiplexedTouchSensor that interprets values from an input that
has multiple switches attached to it. The interface would be the same so
you could pass an instance of MultiplexedTouchSensor to some code that
expects a TouchSensor and it doesn't know the difference.
If a sensor required something different than a basic passive or active
sensor, there would have to be native code to accomodate that.
> Sorry to return to this, but any is going to provide some connection to
> the PC with some library, or even remote debugging capabilities?
One of the reasons for choosing JVM is the development environments already
available for every platform. For debugging, you simply load the classes
which emulate the RCX's hardware and everything else is already there.
As for communication between the PC and the RCX, that is a network protocol
issue that is beyond the scope of the initial project but could easily be
added later.
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
|
|
| |
Wes Matchett wrote:
> My request to both groups is: don't go 'off-list' until you have a feature spec
> that was formed with feedback from the whole list. It would be a shame for you
> to finish development of a tool that no one else uses.
I concur with this opinion. I realize that the subject may be a bit prevalent
right now but the alternative would be to develop a separate list for alternative
firmware discussion, and I don't know how viable that would be.
What follows is a tentative list of new ideas to incorporate into a new bytecode
interpreter that is compatible with the current one:
The original 32 variables become global registers.
Registers numbered 32 to 47 are local to threads. Each thread has its own copy
of these 16 registers. One of these registers is reserved for use as a stack
pointer (I recommend register 32, but it doesn't really matter. Maybe even
allocate one more register for the purpose, numbered 255). I am flexible on the
exact number of thread-local registers, but I do maintain that the count should not
be too high. The amount of space allocated for stack for each thread should also
be kept down (due to the limited RAM on the RCX).
These instructions can be used to manipulate the stack:
push reg
pop reg
To allocate stack space for local variables or to free up stack space used by
parameters and local variables, the existing add and subtract instructions could be
used, specifying as its destination the new register which is designated as stack
pointer.
For data movement to and from registers, I would recommend instructions like the
following:
mov reg,address
mov address,reg
mov reg,address+reg
mov address+reg,reg
mov reg,[reg]
mov [reg],reg
mov reg,[reg]+reg
mov [reg]+reg,reg
And, if you will forgive the intel-ish syntax, similar instructions for accessing
data inside the stack:
mov reg,stack:address
mov stack:address,reg
mov reg,stack:address+reg
mov stack:address+reg,reg
mov reg,stack:[reg]
mov stack:[reg],reg
mov reg,stack:[reg]+reg
mov stack:[reg]+reg,reg
For those of you who may be unfamiliar with concepts of assembly, the notation
[reg] is an indirect addressing mode, where 'reg' contains an address.
For calling subroutines:
call address
call [reg]
The second form permits a robust indirect function call.
On account of the increased size of the interpreter that may result from this
enhanced implementation, it may not be viable to still permit 5 separate programs
to simultaneously be loaded into the RCX. Presently, I don't know how important
this issue might be.
The proposed 20 instructions mentioned above consume just about 1/3 of the total
available opcodes left by the existing interpreter.
These are my first thoughts on the issue. Any comments?
> > Mark
|
|
| |
"John A. Tamplin" wrote:
> One of the reasons for choosing JVM is the development environments already
> available for every platform. For debugging, you simply load the classes
> which emulate the RCX's hardware and everything else is already there.
You have reiterated exactly what I expected would be one of the most popular
reasons to want to implement a JVM for the RCX.
I hope you don't think I'm against what you're attempting to do... it's just that
I, like Kekoa, believe that the endeavor you are about to undertake may transcend
the limits of feasability. There is not a lot of room to play around with inside
the RCX, and Java was developed in an age where memory limitations were largely
being looked at as superfluous on account of ever-diminishing memory costs. I
believe that it may make a JVM for the RCX impossible, or at the very least
impractical. I'd like to be proven wrong, of course.
> > Mark
|
|
| |
So to preface my comments to Mark's message, I should say that even though
I point out technical problems with what he proposes, I do not mean to
imply that these technical problems cannot be overcome.
Mark Tarrabain <markt@lynx.bc.ca> wrote:
> There appear to be 193 opcodes in the existing interpreter. This
> means that there are 63 unused opcodes for possible instructions. This
> should be more than enough to add any extra opcodes necessary to
> transcend the limitations while still being compatible with the older
> bytecode.
There are some technical issues that complicate this, namely, the way the
ROM receives a message depends on the opcode. This is not made obvious
anywhere, but basically the last digit of the opcode indicates the length
of the message. New opcodes and modified versions of old ones have to fit
within this constraint.
Also, each opcode is required (to some extent) to consume two values. You
can relax this restriction if you like, but the cost is that you change the
current IR protocol and you complicate the opcode parser.
> One of the first limitations to be overcome should be the 8
> subroutine limit. At least one new instruction should be added which
> allows the specification of a 16 bit function address, making available
> memory the restrictive aspect rather than merely subroutine count.
As I see it, the current byte code allows for 256 subroutines with no
modifications. Maybe this is not enough, but for all practical purposes I
think it is. Not saying that you can't add another opcode, but if you find
that the opcode space becomes a constraint, you might want to make do with
a 256 subroutine limit. Also, depending on how you design things, using a
16-bit function address might have implications on function relocation,
which the current interpreter uses to keep memory packed in the presence of
additions and deletions of tasks and subroutines.
Regarding using the current 32 global variables as registers, this is a
reasonable way to think of things.
One of the premises of your suggestions seemed to be that byte code
remained completely backward compatible; hence, the suggestion that the 32
global variables (now registers) remain global, and additional registers be
added for local variables. Nothing is wrong with any of this.
One thing you seemed to miss was that the current interpreter only uses 16
of a possible 256 sources. In addition, 3 of the 16 are devoted to
CyberMaster, and could be used by the RCX if you chose to design things
that way. The result is that if you want to use additional sources for
local, global, or thread-local variables (or whatever else you might find
use for additional sources as), you can.
The one caveat is that the test and branch opcodes limit the source
specifier to four bits. However, the encoding for the opsrc parameter of
these opcodes (which currently stores the aforementioned four source bits)
appears to have two bits free. I believe these bits are normally zero.
You can thus use these to bits to allow up to 64 source types.
-Kekoa
|
|
| |
On Thu, 6 May 1999, Mark Tarrabain wrote:
> I hope you don't think I'm against what you're attempting to do... it's just that
> I, like Kekoa, believe that the endeavor you are about to undertake may transcend
> the limits of feasability. There is not a lot of room to play around with inside
> the RCX, and Java was developed in an age where memory limitations were largely
> being looked at as superfluous on account of ever-diminishing memory costs. I
> believe that it may make a JVM for the RCX impossible, or at the very least
> impractical. I'd like to be proven wrong, of course.
Remember that Java's origins came from Oak, which was intended to operate
a Universal remote control. JVM runs on many very tiny computers, and I am
certain that a large subset of Java can be made to fit on the RCX and be a
usable product.
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
|
|
| |
John A. Tamplin <jat@liveonthenet.com> wrote:
> > I was wondering if any of these projects is thinking in providing
> > enough flexibility that would make possible for anyone smoothly
> > integrate new sensors with the currently supported ones? (Like Dennis
> > Clark's RCX IRPD?)
>
> Absolutely. What I have in mind is that the basic level of access is to
> the raw sensor value of the A/D converter and whether it is active or
> passive. The interpretation of that value would be done by other
> classes.
Not that I disagree with the elegance of being able to define a class that
implements a new way of reading a sensor; however, I thought I'd point out
two issues you might want to consider:
First, the ROM already contains a significant amount of non-trivial code to
process the existing sensor types. I would imagine any you would leverage
this code, and you simply did not mention this. To add a new sensor type,
you could use the existing raw type and go at it from there.
Second, processing a sensor is not always as simple as occasionally
checking the value of the sensor; you typically want to process the sensor
value every time an a/d conversion is complete. In my GCC-only world, I
imagined this being done with a system-defined semaphore that does wakes up
all threads waiting on it every time an a/d conversion completes. You
might want your interpreter to provide something similar so you can sync up
sensor processing with a/d conversion.
> > Sorry to return to this, but any is going to provide some connection to
> > the PC with some library, or even remote debugging capabilities?
>
> One of the reasons for choosing JVM is the development environments already
> available for every platform. For debugging, you simply load the classes
> which emulate the RCX's hardware and everything else is already there.
>
> As for communication between the PC and the RCX, that is a network protocol
> issue that is beyond the scope of the initial project but could easily be
> added later.
My take on debugging is to provide IR support for one or two primitives
that are designed to make remote debugging possible. One might allow you
to control how the interpreter executes commands, providing support for
PC-controlled break, step, next, continue, etc.; another might allow you to
do memory dumps, possibly in raw format, possibly with a specifer
indicating a specific chunk of data, e.g. the register set of the current
thread, or possibly some combination of the two.
I should add that IR opcode support is available to the current firmware
and should likely be available to similarly designed new firmware. Similar
JVM support for such IR control, especially in reference to the debugging
features, seems possible but less likely.
I agree with John; the library on the PC is some later business, to be
written at the appropriate time if and when everything else is in place.
-Kekoa
|
|
| |
Kekoa Proudfoot wrote:
>
> There are some technical issues that complicate this, namely, the way the
> ROM receives a message depends on the opcode. This is not made obvious
> anywhere, but basically the last digit of the opcode indicates the length
> of the message. New opcodes and modified versions of old ones have to fit
> within this constraint.
Could you explain what you mean by this, exactly? I would have figured that if
a new interpreter is designed from scratch, the lengths of the opcodes could be
hard-coded into the interpreter in some way. I was not suggesting that any
existing opcodes be modified in length at all..
> Also, each opcode is required (to some extent) to consume two values. You
> can relax this restriction if you like, but the cost is that you change the
> current IR protocol and you complicate the opcode parser.
Could you elaborate on this please? Thanks.
> As I see it, the current byte code allows for 256 subroutines with no
> modifications. Maybe this is not enough, but for all practical purposes I
> think it is. Not saying that you can't add another opcode, but if you find
> that the opcode space becomes a constraint, you might want to make do with
> a 256 subroutine limit. Also, depending on how you design things, using a
> 16-bit function address might have implications on function relocation,
> which the current interpreter uses to keep memory packed in the presence of
> additions and deletions of tasks and subroutines.
Relocation doesn't have to be an issue with 16 bit addresses because the
addresses can be 'start of program' relative. 16 bit addresses for variable
space can also be 'start of data space' relative, so the program can slide
anywhere in memory, as long as it's all kept together. This slows the
interpreter down ever so slightly, since it will need to perform a single add
operation every time an address is referenced, but I would consider the
overhead of a simple operation such as add as negligible for all intents and
purposes.
> Regarding using the current 32 global variables as registers, this is a
> reasonable way to think of things.
>
> One of the premises of your suggestions seemed to be that byte code
> remained completely backward compatible; hence, the suggestion that the 32
> global variables (now registers) remain global, and additional registers be
> added for local variables. Nothing is wrong with any of this.
Thank you. :)
Actually, in fact, I was suggesting that additional registers be added for
"thread-local" variables, and that the stack be used for variables local to a
given function. The stack addressing (and the proposed 16 bit global variable
addressing) would only be used to move data to or from the registers, so
existing opcodes wouldn't have to worry about accomodating the new addressing
modes.
> One thing you seemed to miss was that the current interpreter only uses 16
> of a possible 256 sources. In addition, 3 of the 16 are devoted to
> CyberMaster, and could be used by the RCX if you chose to design things
> that way. The result is that if you want to use additional sources for
> local, global, or thread-local variables (or whatever else you might find
> use for additional sources as), you can.
Actually, I had noticed this, but did not comment on it because the set
variable instruction does not allow a specification of a source mode for the
destination, since a variable is always assumed. It just seemed more practical
to me to use registers numbered above 32 instead, giving full read-write
privileges that are still compatible with the existing opcode set.
> > Mark
|
|
| |
Mark Tarrabain wrote in message <3730DE97.EFB3BF9A@lynx.bc.ca>...
> ...
> I do not believe that a compatible bytecode interpreter can feasibly
> have any floating point routines built into it. Fixed point would need
> to be used at the source code level. It's not that difficult to, at the
> source code level, use everything multiplied by some constant factor
> anyways. This also gives the flexibility of the user being able to use
> whatever precision they decide is appropriate for their particular
> application.
> ...
It is probably true that a floating-point library cannot (should not?) be
built into the firmware. It would probably be better for this to be
supported by the compiler(s). But this still implies that the bytecode
interpreter is actually capable of supporting the necessary atomic
operations upon which a useable floating or fixed-point library can be
built. Which brings me to my point...
I strongly disagree with the common assertion that you can simply revert
to a fixed-point representation under the current 16-bit firmware. I gave
up trying to do any sort of trigonometry because (PLEASE correct me if I'm
wrong) 16 bits are not enough to do even basic calculations in fixed point.
As far as I know, the standard firmware doesn't provide any access to the
overflow and carry bits that are set as the result of simple arithmetic
operations, nor do they allow access to the 32-bit result of a 16-bit
multiply, or the remainder portion of a divide operation. These limitations
make it virtually (?) impossible to do useful fixed-point calculations on
the RCX.
For example, suppose you use 12 bits for the integer portion and a measly
4 bits for the fractional component. This means that you can represent
signed numbers from +- 512 in increments of 1/16. If you multiply 32.0 *
32.0, you will overflow the variable and (because you cannot gain access to
the high word of the result) you cannot regain the lost bits. And the
situation is actually worse than that, because after such a multiply, you
must divide the result by 16 to put the decimal point (binary point?) back
where it belongs, so even multiplying 8.0 * 8.0 will run into overflow
problems, since the top 4 bits of the result are guaranteed to be zero (or
one if the result is negative) after the scale factor correction.
Even if you were to use one 16-bit variable for the whole component and
another for the fraction, you still overflow the variable when you multiply
256.0 * 256.0. And splitting your storage across two variables like this
dramatically increases the number of computations that must be performed in
order to emulate a single arithmetic operation, decreasing efficiency and
increasing code size.
Two firmware improvements would relieve this situation, IMHO. One would
be to support 32-bit integer variables to extend the useable range of simple
fixed-point calculations in user code. The other would be to support an
opcode which performs a combined multiply and divide without losing any bits
during the intermediate operations. (The MS Windows API function MulDiv()
does this.) The MULDIV opcode would take three 16-bit arguments, which I
will call A, B, and C. First, (A * B) is calculated as a 32-bit extended
value. (I don't know, but suspect that the H8 instruction set supports
this.) Then this value is divided by C, yielding a 16-bit result. This
would enable user code to implement fixed-point calculations over a much
larger numeric range without loss of precision or danger of overflow.
I don't know enough about the H8 (yet) to say whether these enhancements
are feasible. But I do know that they are necessary if that little yellow
brick is ever going to do all of the things I am trying to get it to do.
Let me close by saying that I applaud this effort to improve the RCX
firmware, and humbly offer my assistance.
|
|
| |
On Thu, 6 May 1999, Kekoa Proudfoot wrote:
> First, the ROM already contains a significant amount of non-trivial code to
> process the existing sensor types. I would imagine any you would leverage
> this code, and you simply did not mention this. To add a new sensor type,
> you could use the existing raw type and go at it from there.
Unfortunately, the ROM code (as I understand it) does not implement any
mechanism other than polling. I would like to do things like block a
thread until a sensor value matched some criteria. The only efficient
way to do that is to have the A/D-complete interrupt handler signal
waiting threads that their condition has been satisfied.
In my opinion, there should be no interface that only supports polling/busy
waiting. It is ok to make that interface available for people who are more
familiar with it, but there should be interrupt-driven interfaces for
everything.
> Second, processing a sensor is not always as simple as occasionally
> checking the value of the sensor; you typically want to process the sensor
> value every time an a/d conversion is complete. In my GCC-only world, I
> imagined this being done with a system-defined semaphore that does wakes up
> all threads waiting on it every time an a/d conversion completes. You
> might want your interpreter to provide something similar so you can sync up
> sensor processing with a/d conversion.
See above.
> My take on debugging is to provide IR support for one or two primitives
> that are designed to make remote debugging possible. One might allow you
> to control how the interpreter executes commands, providing support for
> PC-controlled break, step, next, continue, etc.; another might allow you to
> do memory dumps, possibly in raw format, possibly with a specifer
> indicating a specific chunk of data, e.g. the register set of the current
> thread, or possibly some combination of the two.
The Java API has extensive support for debugging. However, I think the
reflection API and related elements will not fit into the space available,
as it also reduces the ability to offload some of the class information
to the host.
So, my take is that in general debugging should be performed on the host.
The only debugging on the RCX would be things to verify that the JVM is
working correctly, like tracking memory leaks that aren't being garbage
collected (which can happen naturally with reference loops).
> I should add that IR opcode support is available to the current firmware
> and should likely be available to similarly designed new firmware. Similar
> JVM support for such IR control, especially in reference to the debugging
> features, seems possible but less likely.
The level I would expect to have in the OS/native methods would simply be
buffered send/receive bytes through the IR. Any protocols and "server
ports" on the RCX would be added later and could be loaded only by those
people that want them.
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
|
|
| |
Mark Tarrabain <markt@lynx.bc.ca> wrote:
> Kekoa Proudfoot wrote:
> > There are some technical issues that complicate this, namely, the way
> > the ROM receives a message depends on the opcode. This is not made
> > obvious anywhere, but basically the last digit of the opcode indicates
> > the length of the message. New opcodes and modified versions of old
> > ones have to fit within this constraint.
>
> Could you explain what you mean by this, exactly? I would have figured
> that if a new interpreter is designed from scratch, the lengths of the
> opcodes could be hard-coded into the interpreter in some way. I was not
> suggesting that any existing opcodes be modified in length at all..
Assuming you use the ROM to receive things, which would be prudent in terms
of space but not strictly necessary, the lengths of the opcodes in the
message receiving code are determined by the lowest three bits of the
opcode: 0 means length 0, 1 means length 1, 2-4 mean lengths 2-4, 5 means
the length is stored as part of the data, etc. This is documented in the
RXI code in the Rom section of the web pages. The IR code will fail (i.e.
dump the message) if the length is not as expected.
Maybe you don't intend to allow a subset of the opcodes to be sent from PC
to RCX, or maybe you do not intend to use the ROM to receive messages, and
much of this does not matter.
> > Also, each opcode is required (to some extent) to consume two values. You
> > can relax this restriction if you like, but the cost is that you change the
> > current IR protocol and you complicate the opcode parser.
>
> Could you elaborate on this please? Thanks.
The IR protocol uses the 0x08 bit of the opcodes as a sequence bit to make
sure the same opcode, sent twice because the PC did not receive an
acknowledgement the first time, is not actually executed twice if the RCX
receives it two times. All opcodes sent over IR, with the exception of
0xf7 (set message), therefore take up two values in the opcode number
space, one with the 0x08 bit set, and one with it not set.
Again, if you do not care about sending certain opcodes across IR, you can
relax this restriction, with the caveat that you complicate the parser.
You can do a switch on (opcode & ~0x08), but then for the opcodes that are
doubled up, you have to look at the 0x08 bit to see which opcode was really
intended.
> Relocation doesn't have to be an issue with 16 bit addresses because the
> addresses can be 'start of program' relative.
Only if you disallow changing a subroutine or task without changing the
entire program. As things are now, everything is position independent, and
you can change a single subroutine or task and all the others remain
intact. This is a reasonable thing to lose if you are willing to lose it;
I just thought I'd point out that it breaks the current model for doing
things.
> 16 bit addresses for variable space can also be 'start of data space'
> relative, so the program can slide anywhere in memory, as long as it's
> all kept together.
You have to be careful when relocating data. I'm not sure what your model
of a data space is (is there one data space? how does a task's stack fit
into this? are there pointers? etc.); all I can say is make sure you think
twice about how relocation interacts with your data model if you are going
to allow relocation.
The model I proposed a day or two ago allows relocation by using an index
into one of several data areas/variable frames (function-local, task-local,
global) to allow relocation, and this is similar to what you now seem to be
proposing.
Oh, one nit: by using the word "address" I assumed you meant something that
absolute; if you had instead used the word "offset" I would have known you
were thinking of something relative.
> Actually, in fact, I was suggesting that additional registers be added
> for "thread-local" variables, and that the stack be used for variables
> local to a given function. The stack addressing (and the proposed 16 bit
> global variable addressing) would only be used to move data to or from
> the registers, so existing opcodes wouldn't have to worry about
> accomodating the new addressing modes.
I think the whole notion of a register complicates things somewhat, since
you don't really need registers. Every operation in the byte code uses
source plus argument; if you use one source to access values in a global
data space, another to access values in a thread-local data space, and a
third to access a stack-like function-local data space, you don't need
registers since you can access the three data areas directly. If you want
scratch space, you can allocate data in either the task-local or
function-local data spaces for that purpose. The model I proposed two days
or so ago didn't have registers for exactly these reasons.
> > One thing you seemed to miss was that the current interpreter only uses 16
> > of a possible 256 sources. In addition, 3 of the 16 are devoted to
> > CyberMaster, and could be used by the RCX if you chose to design things
> > that way. The result is that if you want to use additional sources for
> > local, global, or thread-local variables (or whatever else you might find
> > use for additional sources as), you can.
>
> Actually, I had noticed this, but did not comment on it because the set
> variable instruction does not allow a specification of a source mode for
> the destination, since a variable is always assumed. It just seemed more
> practical to me to use registers numbered above 32 instead, giving full
> read-write privileges that are still compatible with the existing opcode
> set.
This is true. My only point was that you don't need a new set of opcodes
to access every new data area you might introduce. Just use different
sources. You might need a single new opcode that stores any single
variable in any source plus argument destination, like set variable but
with the source on the other side.
In the model I proposed, source 0 was for task-local variables, and that
was what I saw being the scratch space. I did not assume backwards
compatibility for source 0 arguments 0..31, but that wouldn't have been
hard to add.
I'm not so sure on the backwards compatibility thing. Can you rattle off a
list of reasons why that might be useful? Here's my list of pros/cons:
+ less firmware reloading for some (since new firmware works as old did)
+ less changes to NQC compiler
+ OCX still works, and so do existing tools
- limits flexibility; cannot reorganize opcode space
- OCX cannot use new features, and is thus somewhat useless
- new tools need to be written no matter what
-Kekoa
|
|
| |
Some comments on what Chris Phillips wrote:
- as far as I know, you will not be able to implement floating point in
byte code, it will be too inefficient (mostly in terms of space)
- agreed, current firmware does not support fixed point well, and it is
because they do not allow 32-bit values
- yes, you need 32-bit values for usable fixed point in byte code
- muldiv also useful
- muldiv not supported natively by H8
- have you considered writing native code?
-Kekoa
|
|
| |
John A. Tamplin <jat@liveonthenet.com> wrote:
> On Thu, 6 May 1999, Kekoa Proudfoot wrote:
>
> > First, the ROM already contains a significant amount of non-trivial code to
> > process the existing sensor types. I would imagine any you would leverage
> > this code, and you simply did not mention this. To add a new sensor type,
> > you could use the existing raw type and go at it from there.
>
> Unfortunately, the ROM code (as I understand it) does not implement any
> mechanism other than polling. I would like to do things like block a
> thread until a sensor value matched some criteria. The only efficient
> way to do that is to have the A/D-complete interrupt handler signal
> waiting threads that their condition has been satisfied.
What is your point? If you want to make sense of the raw values, and want
to leverage the ROM code to process the existing sensor types/modes, you
need to call a ROM sensor-processing function every time an a/d completes.
That was the point I was trying to make.
The ROM a/d isr, which is different from the ROM sensor-processing function
I mentioned, effectively does the efficient thing you mentioned. It
effectively throws a semaphore which causes the firmware's
sensor-processing code to run at high priority.
The LegOS a/d code only supports polling.
There is no reason the a/d code you end up using can't effectively wake up
a task devoted to a/d processing. This is completely independent from
using the ROM sensor-processing code.
> So, my take is that in general debugging should be performed on the host.
> The only debugging on the RCX would be things to verify that the JVM is
> working correctly, like tracking memory leaks that aren't being garbage
> collected (which can happen naturally with reference loops).
You mean that in general, for the JVM. The other byte code that is being
considered, which is not based on the JVM, and which I was talking about
when discussing debugging methods, would likely use the debugging methods I
described; I don't think you disagree with this, but maybe you
misunderstood - I was not talking about the JVM.
-Kekoa
|
|
| |
On Thu, 6 May 1999, Kekoa Proudfoot wrote:
> The ROM a/d isr, which is different from the ROM sensor-processing function
> I mentioned, effectively does the efficient thing you mentioned. It
> effectively throws a semaphore which causes the firmware's
> sensor-processing code to run at high priority.
Obviously you have spent much more time deciphering the ROM than I have.
I wasn't aware that the ROM supported native threads, only multiplexing
the bytecode streams it executed. How can replacement firmware hook into
this sensor-processing code?
> You mean that in general, for the JVM. The other byte code that is being
> considered, which is not based on the JVM, and which I was talking about
> when discussing debugging methods, would likely use the debugging methods I
> described; I don't think you disagree with this, but maybe you
> misunderstood - I was not talking about the JVM.
Sorry for the confusion.
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
|
|
| |
In lugnet.robotics, markt@lynx.bc.ca (Mark Tarrabain) writes:
> Wes Matchett wrote:
> > My request to both groups is: don't go 'off-list' until you have a feature
> > spec that was formed with feedback from the whole list. It would be a
> > shame for you to finish development of a tool that no one else uses.
>
> I concur with this opinion. I realize that the subject may be a bit
> prevalent right now but the alternative would be to develop a separate list
> for alternative firmware discussion, and I don't know how viable that would
> be.
That's a good pseudo-question. It would actually be quite easy to set up a
focused group/list for this, as has been done for legOS, NQC, and pbFORTH;
the viability is only dependent on the interest in having more room to
breathe. Anything really important can be crossposted for increased
visibility, with followups set as appropriate.*
The lugnet.robotics newsgroup hierarchy accommodates expansion as new topics
arise. So, for example, if a subgroup is for alternative firmware
discussions is desired, one possibility is naming it as a subgroup of
.robotics.rcx -- or .rcx itself could even be used for this (since
lugnet.robotics.rcx is currently a reserved/empty node in the ng tree,
existing originally only to structure its 3 subgroups .rcx.legos, .rcx.nqc,
and .rcx.pbforth).
The reason that lugnet.robotics.rcx wasn't created (as a newsgroup) at the
same time its three subgroups were created is that, at the time, no one
wanted to talk about other alternative firmware possibilities.
It may just make sense to bite the bullet, create the group, and let it sit
and either blossom or die, depending on how the winds end up blowing on
this.
--Todd
* The technical details:
All lugnet newsgroups are:
- real newsgroups served by a real NNTP server from multiple ports (119,
8000, and 8080)
- subscribeable via e-mail as instantaneous messages or in digest form at
user-specified intervals
- archived and searchable via an HTTP web interface (which is also a
threaded newsreader)
- part of an integrated body of hundreds of LEGO-specific newsgroups
|
|
| |
John A. Tamplin <jat@liveonthenet.com> wrote:
> On Thu, 6 May 1999, Kekoa Proudfoot wrote:
>
> > The ROM a/d isr, which is different from the ROM sensor-processing function
> > I mentioned, effectively does the efficient thing you mentioned. It
> > effectively throws a semaphore which causes the firmware's
> > sensor-processing code to run at high priority.
>
> Obviously you have spent much more time deciphering the ROM than I have.
> I wasn't aware that the ROM supported native threads, only multiplexing
> the bytecode streams it executed. How can replacement firmware hook into
> this sensor-processing code?
I've mislead you. The ROM does not support native threads. The firmware
simulates cooperative threads. The firmware selects one of six functions
to run based on priority and whether or not a run flag has been set for
that function. The run flag operates like a semaphore. A function is
selected, then called; it does something, then returns. The process
repeats. This simulates a threaded system. The sensor processing code has
the highest priority.
Technically, I would not call this a threaded system, but it operates just
like a cooperatively threaded system, but without the stack overhead.
-Kekoa
|
|
| |
John A. Tamplin <jat@liveonthenet.com> wrote:
> Obviously you have spent much more time deciphering the ROM than I have.
> I wasn't aware that the ROM supported native threads, only multiplexing
> the bytecode streams it executed. How can replacement firmware hook into
> this sensor-processing code?
I didn't answer your question with the last message.
The ROM does not execute byte codes, the firmware does. The firmware
multiplexes between byte codes.
I'm not sure what you mean by how can replacement firmware hook into the
sensor processing code. Assuming you read my last message, the firmware
would (when it got around to it) look at the bit for the sensor handler,
see that it was set, and call the ROM sensor-processing code three times,
once for each sensor. So the hook into the sensor-processing code is a
function call into the ROM.
I should revise what I said about the ROM/firmware doing the efficient
thing you had mentioned a while ago now. The firmware really polls what I
called the semaphore, so that not as efficient as it could be. But it is
not contintually polling and processing the sensors, which is where the
majority of the work is.
-Kekoa
|
|
| |
On Thu, 6 May 1999, Kekoa Proudfoot wrote:
> I'm not sure what you mean by how can replacement firmware hook into the
> sensor processing code. Assuming you read my last message, the firmware
> would (when it got around to it) look at the bit for the sensor handler,
> see that it was set, and call the ROM sensor-processing code three times,
> once for each sensor. So the hook into the sensor-processing code is a
> function call into the ROM.
>
> I should revise what I said about the ROM/firmware doing the efficient
> thing you had mentioned a while ago now. The firmware really polls what I
> called the semaphore, so that not as efficient as it could be. But it is
> not contintually polling and processing the sensors, which is where the
> majority of the work is.
Thanks, I think I understand how it works.
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
|
|
| |
Kekoa Proudfoot wrote in message ...
> Some comments on what Chris Phillips wrote:
>
> - as far as I know, you will not be able to implement floating point in
> byte code, it will be too inefficient (mostly in terms of space)
Do you think it would be possible with improved firmware to support
inline H8 code embedded in a user program? For example, a special byte code
could indicate that the following code should be executed directly by a
subroutine CALL until it decided to RETurn? This might allow compilers to
embed high-performance, efficient library code into a user program instead
of relying on the firmware to implement every feature, or byte code
operations to support every possibility.
> - agreed, current firmware does not support fixed point well, and it is
> because they do not allow 32-bit values
> - yes, you need 32-bit values for usable fixed point in byte code
> - muldiv also useful
> - muldiv not supported natively by H8
I'm not surprised that MulDiv isn't supported directly by the H8. But do
you know if the H8's MULtiply instruction returns a 32-bit value? (On
16-bit 80x86 processors, for example, this is done using two registers: AX
for the low word and DX for the high word of the result.) I believe that
this would be a requirement for implementing a MULDIV byte code on the RCX.
> - have you considered writing native code?
I actually have considered writing native H8 code. Unfortunately, I have
been stymied by several factors:
1. The web link from the Lego Mindstorms Internals web page to the
"Download H8 Software Manual" appears to be broken. I spent awhile scouring
Hitachi's web page for this vital document without success. (If anyone
knows a current URL for this, I would be eternally grateful.)
2. I haven't yet gotten LegOs installed. I'm not sure if there's a
problem with the latest TAR file that I downloaded, but whenever I try to
expand it, I get errors. (I am running out of disk space, but it appears
that the TAR file is expanding in size by a factor of ten before that
happens which makes me suspicious that the file might be corrupted.)
3. I don't have the GCC environment loaded either. (What can I say,
I'm a Windows dweeb.) I've been looking for a good excuse to install Linux
on one of my old machines, and this might be it.
I do plan on conquering all of these problems in the very near future,
though, since I quickly realized that the standard Lego firmware isn't going
to keep up with me for very long. And after all, my offer to help write a
new & improved firmware wouldn't hold much water if I wasn't planning to get
set up to write H8 code.
|
|
| |
Well, now that you mention it...
lugnet.robotics.rcx.misc might be the best way to go. That seems to have the most
consistency with existing groups.
If that group's discussion splinters considerably, then new groups could be
created in the l.r.r.* hierarchy for those interests when the traffic warrants it,
but at least the .misc group would exist for future discussion of yet more new
ideas.
I was suggesting this sort of group back when the creation of the nqc and legos
newsgroups were first being discussed, but I suppose the demand was not high
enough for a general purpose rcx group. Maybe I was just ahead of my time. (or
maybe I'm just full of myself...:)
> > Mark
|
|
| |
Chris Phillips wrote:
> Do you think it would be possible with improved firmware to support
> inline H8 code embedded in a user program? For example, a special byte code
> could indicate that the following code should be executed directly by a
> subroutine CALL until it decided to RETurn? This might allow compilers to
> embed high-performance, efficient library code into a user program instead
> of relying on the firmware to implement every feature, or byte code
> operations to support every possibility.
Good idea! I like it! The only problem I can see with this is I'm not sure if
the H8 supports position independant code or not. If it does, then there's no
problem.
> > Mark
|
|
| |
Chris Phillips <chris.phillips@computerboards.com> wrote:
> Do you think it would be possible with improved firmware to support
> inline H8 code embedded in a user program? For example, a special byte code
> could indicate that the following code should be executed directly by a
> subroutine CALL until it decided to RETurn? This might allow compilers to
> embed high-performance, efficient library code into a user program instead
> of relying on the firmware to implement every feature, or byte code
> operations to support every possibility.
You might be able to do this if you were clever about it; you might be able
to define an opcode that defines a native subroutine that you can call with
another opcode, say, that passes in 16- or 32-bit values in registers and
expects you store the result in registers also, something like how the math
routines work now. Somebody mentioned position independent code (or the
lack thereof); the RCX doesn't support this well because PC-relative
branches only have the range of a signed char. GCC at least uses absolute
jumps in place of longer branches.
I think inserting native code is getting a bit overkill, but that is just
my $0.02.
> I'm not surprised that MulDiv isn't supported directly by the H8. But do
> you know if the H8's MULtiply instruction returns a 32-bit value? (On
> 16-bit 80x86 processors, for example, this is done using two registers: AX
> for the low word and DX for the high word of the result.) I believe that
> this would be a requirement for implementing a MULDIV byte code on the RCX.
Actually, the H8 is worse than this. It only supports 8-bit multiplies,
storing the result in a 16-bit register. 16-bit and 32-bit operations are
supported in software by routines located in ROM.
> > - have you considered writing native code?
>
> I actually have considered writing native H8 code. Unfortunately, I have
> been stymied by several factors:
I asked the question because, from the things it sounded like you wanted to
do, LegOS might be a better development environment for your needs. Then
again, you are clearly one of the people who is running into trouble with
the development environment, which can be a complete pain. (I know how it
is, it took me a while to get it set up on my everyday machine.)
Also, that you want to do firmware development also means you need to get
over the hurdle :)
-Kekoa
|
|
| |
Kekoa Proudfoot <kekoa@pixel.Stanford.EDU> wrote:
> Chris Phillips <chris.phillips@computerboards.com> wrote:
> > I'm not surprised that MulDiv isn't supported directly by the H8.
> > But do you know if the H8's MULtiply instruction returns a 32-bit
> > value? (On 16-bit 80x86 processors, for example, this is done using
> > two registers: AX for the low word and DX for the high word of the
> > result.) I believe that this would be a requirement for implementing a
> > MULDIV byte code on the RCX.
>
> Actually, the H8 is worse than this. It only supports 8-bit multiplies,
> storing the result in a 16-bit register. 16-bit and 32-bit operations are
> supported in software by routines located in ROM.
I should clarify this. The 16-bit software multiply takes two 16-bit
numbers and stores their product in a 16-bit number. The 32-bit software
multiply takes two 32-bit numbers and stores their product in a 32-bit
number. The operations are intended to support C-style short and long
multiplies. The upshot is that to do 16-bit fixed point, you have to use
32-bit multiplies. No biggie, I just didn't want to mislead you into
thinking you could get 64-bit temporaries out of any of this.
-Kekoa
|
|
| |
Kekoa Proudfoot wrote:
>
> I'm not so sure on the backwards compatibility thing. Can you rattle off a
> list of reasons why that might be useful? Here's my list of pros/cons:
>
> + less firmware reloading for some (since new firmware works as old did)
> + less changes to NQC compiler
> + OCX still works, and so do existing tools
> - limits flexibility; cannot reorganize opcode space
> - OCX cannot use new features, and is thus somewhat useless
> - new tools need to be written no matter what
At the risk of splintering the development efforts here from 2 to three, I've been
wondering the same thing. I guess I'm not as concerned with ensuring that my
existing OCX code works - I'd rather see any new OS make the RCX "be all that it
can be".
But, is that what legOS is? Trying to remember back to the genesis of this thread
- is the only complaint about legOS that it's too difficult to
install/learn/program in? Or are there limitations in legOS that would be overcome
in a complete re-architecture of the bytecode? (I'm planning to jump into legOS
and find out for myself, soon - as soon as I "finish" my current bot.)
Thanks,
Mark David
|
|
| |
"Mark R. David" wrote:
> But, is that what legOS is? Trying to remember back to the genesis of this thread
> - is the only complaint about legOS that it's too difficult to
> install/learn/program in? Or are there limitations in legOS that would be overcome
> in a complete re-architecture of the bytecode? (I'm planning to jump into legOS
> and find out for myself, soon - as soon as I "finish" my current bot.)
There are no limitations in LegOS at all that I am aware of. The biggest problems with
LegOS are the size of and number of tools required work with it and the learning curve
for people who don't have any prior programming experience (let alone C programming
experience). NQC, or something similar, has the merit of being "small" and thereby
feasibly learnable by people who don't have any programming exerience at all before
playing around with the RCX. My 15 year old quickly recognized the limitations of the
RIS system and I pointed him towards other options like NQC and LegOS. He had no
problems learning NQC but even after grasping the basic concepts behind C as
implemented in NQC, he found LegOS intimidating.
> > Mark
|
|
| |
Mark Tarrabain wrote:
>
> "John A. Tamplin" wrote:
>
> > One of the reasons for choosing JVM is the development environments already
> > available for every platform. For debugging, you simply load the classes
> > which emulate the RCX's hardware and everything else is already there.
>
> You have reiterated exactly what I expected would be one of the most popular
> reasons to want to implement a JVM for the RCX.
>
> I hope you don't think I'm against what you're attempting to do... it's just that
> I, like Kekoa, believe that the endeavor you are about to undertake may transcend
> the limits of feasability. There is not a lot of room to play around with inside
> the RCX, and Java was developed in an age where memory limitations were largely
> being looked at as superfluous on account of ever-diminishing memory costs. I
> believe that it may make a JVM for the RCX impossible, or at the very least
> impractical. I'd like to be proven wrong, of course.
For the record, up until recently I agreed with you.
However, after hearing further discussions I think it is possible.
The biggest hurdle is probably garbage collection since this is what
causes Java's propensity to "gobble" memory.
The class files themselves are relatively compact. My
original objections revolved around all of the extra stuff they
contain to make dynamic linking, etc. possible. Discussions here
made me realize that the RCX would have to be treated as the JVM
and not just some OS running a JVM. The PC side would be
responsible for loading and validating classes and then transferring
them into the RCX. This does impose some limitations but I think
they are acceptable.
Reflection capability should be removed which will allow
us to get away from keeping method and class names around. These
are prime memory wasters in a non-GUI environment.
I think making a non-compliant JVM as described is definitely
possible. I also think it is alot of work. I wish I had some time
to put into it because it sounds like fun. A little embedded
experience on the ol' resume might be nice too, even if it is only
Lego. :)
-Paul (pspeed@progeeks.com, http://www.progeeks.com)
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
I request that the discussions of alternate firmware implementation details
go into their own newsgroup now. Discussions about features can be
crossposted to both lists. There were several requests recently to create
a new group for newbies to discuss building tips and novice comments. We
decided to keep newbies on this list so that they could benefit from the
assistance of more knowledgeable gurus. However, the type and volume of
computer science discussions that have been occurring on this list recently
could really drive the newbies away. I think that the current list should
continue to be a place where a teenager could go and learn more about his
RCX and programming in general without feeling overwhelmed. Not that the
current list shouldn't support very technical discussions, just not the
volume of these discussions that we've experienced lately.
Just MHO.
At 09:44 PM 5/6/99 +0000, you wrote:
> In lugnet.robotics, markt@lynx.bc.ca (Mark Tarrabain) writes:
> > Wes Matchett wrote:
> > > My request to both groups is: don't go 'off-list' until you have a • feature
> > > spec that was formed with feedback from the whole list. It would be a
> > > shame for you to finish development of a tool that no one else uses.
> >
> > I concur with this opinion. I realize that the subject may be a bit
> > prevalent right now but the alternative would be to develop a separate list
> > for alternative firmware discussion, and I don't know how viable that would
> > be.
>
> That's a good pseudo-question. It would actually be quite easy to set up a
> focused group/list for this, as has been done for legOS, NQC, and pbFORTH;
> the viability is only dependent on the interest in having more room to
> breathe. Anything really important can be crossposted for increased
> visibility, with followups set as appropriate.*
>
> The lugnet.robotics newsgroup hierarchy accommodates expansion as new topics
> arise. So, for example, if a subgroup is for alternative firmware
> discussions is desired, one possibility is naming it as a subgroup of
> .robotics.rcx -- or .rcx itself could even be used for this (since
> lugnet.robotics.rcx is currently a reserved/empty node in the ng tree,
> existing originally only to structure its 3 subgroups .rcx.legos, .rcx.nqc,
> and .rcx.pbforth).
>
> The reason that lugnet.robotics.rcx wasn't created (as a newsgroup) at the
> same time its three subgroups were created is that, at the time, no one
> wanted to talk about other alternative firmware possibilities.
>
> It may just make sense to bite the bullet, create the group, and let it sit
> and either blossom or die, depending on how the winds end up blowing on
> this.
>
> --Todd
>
> * The technical details:
> All lugnet newsgroups are:
> - real newsgroups served by a real NNTP server from multiple ports (119,
> 8000, and 8080)
> - subscribeable via e-mail as instantaneous messages or in digest form at
> user-specified intervals
> - archived and searchable via an HTTP web interface (which is also a
> threaded newsreader)
> - part of an integrated body of hundreds of LEGO-specific newsgroups
> --
> Did you check the web site first?: http://www.crynwr.com/lego-robotics
Joel Shafer joel@connect.net
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
[Crossposted to lugnet.robotics & lugnet.announce; followups set to
lugnet.robotics & lugnet.robotics.rcx]
All right -- better late than never... A new group lugnet.robotics.rcx has
been created, and is there now for anyone wants to jump in and use it.
This new group is a missing link in the newsgroup hierarchy -- it sits
below the robotics group and above the LegOS, NQC, and pbFORTH groups,
using a previously unused (reserved) spot in the newsgroup hierarchy.
Here is the full context:
lugnet.robotics (group and hierarchy):
Building, creating, and developing with added technologies: the
LEGO® MINDSTORMS™ RIS, other programmable bricks, vision systems,
bar-code readers, radio controlled units, research sites, microcode/
embedded programming, etc.
-> lugnet.robotics.rcx (group and hierarchy):
Alternative firmware for RCX programmable brick from LEGO®
MINDSTORMS™ RIS: in-depth technical discussions, collaboration,
planning, architecture, analysis, etc.
lugnet.robotics.rcx.legos (group):
Focused discussion group for legOS, an unofficial replacement
firmware package for the LEGO® MINDSTORMS™ RIS: in-depth technical
discussions, collaboration, planning, architecture, analysis,
release schedules, problem reports, success stories, etc.
lugnet.robotics.rcx.nqc (group):
Focused discussion group for NQC ("Not Quite C"), an unofficial
language and compiler for programming the LEGO® MINDSTORMS™ RIS:
in-depth technical discussions, collaboration, planning,
architecture, analysis, release schedules, problem reports, success
stories, etc.
lugnet.robotics.rcx.pbforth (group):
Focused discussion group for pbFORTH, an unofficial replacement
firmware package for the LEGO® MINDSTORMS™ RIS: in-depth technical
discussions, collaboration, planning, architecture, analysis,
release schedules, problem reports, success stories, etc.
(Note that it is perfectly OK to crosspost between the various groups,
as appropriate.)
TO SUBSCRIBE
============
To participate via NNTP (netnews), point your newsreader here:
news://lugnet.com/lugnet.robotics.rcx
or news://lugnet.com:8000/lugnet.robotics.rcx
or news://lugnet.com:8080/lugnet.robotics.rcx
Or, to participate via HTTP (web interface), point your web browser here:
http://www.lugnet.com/news/display.cgi/?lugnet.robotics.rcx
Or, to subscribe via SMTP (e-mail), point your web browser here:
http://www.lugnet.com/news/mail/
To register for posting to any LUGNET group (if you haven't yet done so),
point your web browser here:
http://www.lugnet.com/news/post/setup/
--Todd
|
|
| |
Hi.
Hope I can jump in here and ask where a newby who knows he's in the deep end in computer science
discussions, - knows he's taking in water, coughing and spluttering but loving every minute of it -
go to ask elementary questions like:
What's a class library?
How do you define function-local variables / recursion / global variables /
dynamic memory allocation / dymamic string allocation /
object oriented programming, for Christopher's sake?
I know this is basic stuff for some and could take up vast yards of bandwidth but I need to find
guidance somewhere.
Some teenagers might have got the MindStorms RIS to learn robotics, but I got it to learn
programming while having a blast. OK, I'm a doctor, so I'm used to tackling vast heaps of technical
definitions and description, but I bet there are others out there who came here for the same reason.
I bet we could, in one group or the other, steadily build up a FAQ full of relevant definitions for
would-be hackers. Or pointers to sources of reference, preferably on the net. Any ideas?
Please pardon me if I've overlooked an existing source for this kind of newby knowledge. I scrolled
through the whole (awesome) homepage looking.
Thanks for the opportunity to be a fly on the wall at the fascinating discussion, this last week.
Regards,
Ko-LIIN.
Joel Shafer wrote:
>
> I request that the discussions of alternate firmware implementation details
> go into their own newsgroup now. Discussions about features can be
> crossposted to both lists. There were several requests recently to create
> a new group for newbies to discuss building tips and novice comments. We
> decided to keep newbies on this list so that they could benefit from the
> assistance of more knowledgeable gurus. However, the type and volume of
> computer science discussions that have been occurring on this list recently
> could really drive the newbies away. I think that the current list should
> continue to be a place where a teenager could go and learn more about his
> RCX and programming in general without feeling overwhelmed. Not that the
> current list shouldn't support very technical discussions, just not the
> volume of these discussions that we've experienced lately.
>
> Just MHO.
>
> At 09:44 PM 5/6/99 +0000, you wrote:
> > In lugnet.robotics, markt@lynx.bc.ca (Mark Tarrabain) writes:
> > > Wes Matchett wrote:
> > > > My request to both groups is: don't go 'off-list' until you have a • feature
> > > > spec that was formed with feedback from the whole list. It would be a
> > > > shame for you to finish development of a tool that no one else uses.
> > >
> > > I concur with this opinion. I realize that the subject may be a bit
> > > prevalent right now but the alternative would be to develop a separate list
> > > for alternative firmware discussion, and I don't know how viable that would
> > > be.
> >
> > That's a good pseudo-question. It would actually be quite easy to set up a
> > focused group/list for this, as has been done for legOS, NQC, and pbFORTH;
> > the viability is only dependent on the interest in having more room to
> > breathe. Anything really important can be crossposted for increased
> > visibility, with followups set as appropriate.*
> >
> > The lugnet.robotics newsgroup hierarchy accommodates expansion as new topics
> > arise. So, for example, if a subgroup is for alternative firmware
> > discussions is desired, one possibility is naming it as a subgroup of
> > .robotics.rcx -- or .rcx itself could even be used for this (since
> > lugnet.robotics.rcx is currently a reserved/empty node in the ng tree,
> > existing originally only to structure its 3 subgroups .rcx.legos, .rcx.nqc,
> > and .rcx.pbforth).
> >
> > The reason that lugnet.robotics.rcx wasn't created (as a newsgroup) at the
> > same time its three subgroups were created is that, at the time, no one
> > wanted to talk about other alternative firmware possibilities.
> >
> > It may just make sense to bite the bullet, create the group, and let it sit
> > and either blossom or die, depending on how the winds end up blowing on
> > this.
> >
> > --Todd
> >
> > * The technical details:
> > All lugnet newsgroups are:
> > - real newsgroups served by a real NNTP server from multiple ports (119,
> > 8000, and 8080)
> > - subscribeable via e-mail as instantaneous messages or in digest form at
> > user-specified intervals
> > - archived and searchable via an HTTP web interface (which is also a
> > threaded newsreader)
> > - part of an integrated body of hundreds of LEGO-specific newsgroups
> > --
> > Did you check the web site first?: http://www.crynwr.com/lego-robotics
>
> Joel Shafer joel@connect.net
>
> --
> Did you check the web site first?: http://www.crynwr.com/lego-robotics
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
Paul Speed wrote:
> For the record, up until recently I agreed with you.
> However, after hearing further discussions I think it is possible.
> The biggest hurdle is probably garbage collection since this is what
> causes Java's propensity to "gobble" memory.
This is FUD.
What causes Java to gobble memory is more likely (a) the amount of
header overhead it places on objects (more to do with hashing support
than gc, I suspect) and (b), to a lesser extent, the fact that objects
are never "expanded" in place but always pay an additional pointer
overhead.
The space overhead for garbage collection per se is quite small, near
zero if you stop the interpreter during gc and every object has a method
table; even if you do full traversal (obviating all need for type tags
if you are clever) the temp space is proportional only to the square
root of heap size and a couple of marking bits in each pointer (using
technology 25 years out of date; there may be a better bound by now).
But think about it: a garbage collector can release memory *as soon as
is logically possible*. This *must* be no worse than an explicit-release
system. If the gc waits longer, that is a pure - and automatically
managed - time/space tradeoff.
stephen (who still isn't sanguine about RCX Java but hates to see a
language attacked for its *good* features)
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
On Fri, 7 May 1999, stephen p spackman wrote:
> What causes Java to gobble memory is more likely (a) the amount of
> header overhead it places on objects (more to do with hashing support
> than gc, I suspect) and (b), to a lesser extent, the fact that objects
> are never "expanded" in place but always pay an additional pointer
> overhead.
Java is not particularly space efficient (in typical implementations) for
several reasons:
1) value stacks are stored as a union of all the types you can store in
a variable, so you eat up at least 32 bits (64 on an implementation
supporting long/double). Arrays don't waste space that way, however.
2) late binding requires keeping the names of the methods around in RAM,
so a typical implementation has lots of memory devoted to constant
strings.
3) JVM keeps a fair amount of data about each class and object. If most
objects are small, the overhead can become a significant part of the
overall storage.
Hashing is nothing more than a single method, which is typically inherited
from java.lang.Object and thus consumes no space on most objects. The
extra pointer indirection is an implementation detail in Sun's JVM (so they
can relocate objects during GC without having to update all the pointers),
and even so only applies to arrays and object references which are typically
much larger than the object so the cost is relatively small.
> The space overhead for garbage collection per se is quite small, near
> zero if you stop the interpreter during gc and every object has a method
> table; even if you do full traversal (obviating all need for type tags
> if you are clever) the temp space is proportional only to the square
> root of heap size and a couple of marking bits in each pointer (using
> technology 25 years out of date; there may be a better bound by now).
There are many ways to do GC. All involve a trade-off between time and
space. Typical algorithms add at least 2 bits for each cell (many GC
schemes are built on Dykstra's 3-color scheme developed 27 years ago),
or dividing the available memory in half and only allocating new cells in
the active half. Either approach has space overhead, and they have varying
effects on runtime efficiency.
> But think about it: a garbage collector can release memory *as soon as
> is logically possible*. This *must* be no worse than an explicit-release
> system. If the gc waits longer, that is a pure - and automatically
> managed - time/space tradeoff.
You are not counting the time to compute the reference graph, which can
be quite substantial for a large number of small objects. GC has its place,
and in general I agree that reducing programmer complexity for increasing
resource requirements is a good tradeoff. However, on a small system it is
harder to make that tradeoff, and I would prefer to have explicit storage
management. Of course, changing that would completely eliminate the benefits
of using JVM in the first place.
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
|
|
| |
John A. Tamplin wrote:
>
> On Fri, 7 May 1999, stephen p spackman wrote:
>
> > What causes Java to gobble memory is more likely (a) the amount of
> > header overhead it places on objects (more to do with hashing support
> > than gc, I suspect) and (b), to a lesser extent, the fact that objects
> > are never "expanded" in place but always pay an additional pointer
> > overhead.
>
> Java is not particularly space efficient (in typical implementations) for
> several reasons:
> 1) value stacks are stored as a union of all the types you can store in
> a variable, so you eat up at least 32 bits (64 on an implementation
> supporting long/double). Arrays don't waste space that way, however.
Sure: one aspect of the "expanded" issue.
> 2) late binding requires keeping the names of the methods around in RAM,
> so a typical implementation has lots of memory devoted to constant
> strings.
Well, dynamic loading, not late binding; this stuff would not be on the
RCX - presumably almost all of the class loader remains on the host
machine, with downloaded code pre-linked and pre-verified. You'd be
truly silly not to split the symbol table - I don't think introspection
will be heavily used in this environment :-).
> 3) JVM keeps a fair amount of data about each class and object. If most
> objects are small, the overhead can become a significant part of the
> overall storage.
Yep.
> Hashing is nothing more than a single method, which is typically inherited
> from java.lang.Object and thus consumes no space on most objects. The
> extra pointer indirection is an implementation detail in Sun's JVM (so they
> can relocate objects during GC without having to update all the pointers),
> and even so only applies to arrays and object references which are typically
> much larger than the object so the cost is relatively small.
Am I wrong? Most systems that provide hashing of mutable objects either
go to great lengths to ensure that objects never relocate, or actually
CHOOSE a hash code at object creation and STORE it in the object. Either
approach requires space overhead: either a pointer somewhere or a hash
value.
So it looks to me that the minimum size of java.lang.Object is three
pointers (the pointer to the object, the vtable, the hash mechanism),
and measurements suggest it is actually much bigger.
> > The space overhead for garbage collection per se is quite small, near
> > zero if you stop the interpreter during gc and every object has a method
> > table; even if you do full traversal (obviating all need for type tags
> > if you are clever) the temp space is proportional only to the square
> > root of heap size and a couple of marking bits in each pointer (using
> > technology 25 years out of date; there may be a better bound by now).
>
> There are many ways to do GC. All involve a trade-off between time and
> space. Typical algorithms add at least 2 bits for each cell (many GC
> schemes are built on Dykstra's 3-color scheme developed 27 years ago),
> or dividing the available memory in half and only allocating new cells in
> the active half. Either approach has space overhead, and they have varying
> effects on runtime efficiency.
Actually I would have said that "typical" algorithms were now at least
ephemeral and require very little overhead of any kind. But those work
best in large virtual memories, so they aren't the ones we're discussing
here.
> > But think about it: a garbage collector can release memory *as soon as
> > is logically possible*. This *must* be no worse than an explicit-release
> > system. If the gc waits longer, that is a pure - and automatically
> > managed - time/space tradeoff.
>
> You are not counting the time to compute the reference graph, which can
> be quite substantial for a large number of small objects. GC has its place,
Nono, that was a space analysis; recall that I was replying to an
objection that there was no *room* for a gc on the RCX. Of *course*
there is time overhead in this situation; a time overhead which I
calculate to be comparable to that of using an interpreter rather than
compiled code (that is, a small few instructions per "useful"
instruction).
> and in general I agree that reducing programmer complexity for increasing
> resource requirements is a good tradeoff. However, on a small system it is
> harder to make that tradeoff, and I would prefer to have explicit storage
> management. Of course, changing that would completely eliminate the benefits
> of using JVM in the first place.
Which was the conclusion I too had come to, though garbage collection
was not on my own list of features to omit.
stephen
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
Aa-Tchoo! wrote:
>
> Hi.
>
> Hope I can jump in here and ask where a newby who knows he's in the deep end in computer science
> discussions, - knows he's taking in water, coughing and spluttering but loving every minute of it -
> go to ask elementary questions like:
> What's a class library?
> How do you define function-local variables / recursion / global variables /
> dynamic memory allocation / dymamic string allocation /
> object oriented programming, for Christopher's sake?
> I know this is basic stuff for some and could take up vast yards of bandwidth but I need to find
> guidance somewhere.
I'm going out of town and have to run for the bus ayt any moment, so I'm
afraid I don't get to answer your questions.
But a quick comment to those who are contemplating what the New
Environment should be:
You see? Not everyone out there wants or needs a Java. With a properly
designed language _not one_ of these concepts would need explaining -
though most of them would fall out as "huh, that's obvious, you need a
_word_ for that?" concepts.
Really, Java is much more complex - and less powerful - than it needs to
be, just because of the market necessity to be like C++.
Why can we not be free of this? The impediment is not technical.
stephen (who thinks a Java port to the RCX *would* be cool, but who just
doesn't think it meets the brief of "something simpler and more powerful
that everyone could enjoy using" - I mean, why not port Emacs lisp ;->)
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
stephen p spackman wrote:
> But think about it: a garbage collector can release memory *as soon as
> is logically possible*. This *must* be no worse than an explicit-release
> system. If the gc waits longer, that is a pure - and automatically
> managed - time/space tradeoff.
In environments which provide general purpose pointer types which can be
assigned to addresses of explicitly allocated memory (like C and C++),
garbage collection becomes an NP-hard problem. In environments which have
no end-user accessible pointer type, explicit memory allocation is
superfluous.
> > Mark
|
|
| |
stephen p spackman wrote:
>
> Paul Speed wrote:
>
> > For the record, up until recently I agreed with you.
> > However, after hearing further discussions I think it is possible.
> > The biggest hurdle is probably garbage collection since this is what
> > causes Java's propensity to "gobble" memory.
>
> This is FUD.
Hmmm... I guess I have to explain every little word I write
so as not to get flamed.
People fear Java on a small memory platform because when
they run a JVM for any length of time on their Wintel boxes they
see it slowly "gobble" more and more and more memory up to about
70-96 meg depending on internal JVM overhead for the heap that's
been created. By default, the 1.2 JVM has a max heap set at 64 meg.
The docs say otherwise, but trust me on this one.
The garbage collector won't run unless certain conditions
are met. One of these conditions is that the amount of free memory
available is very small.... so GC doesn't usually happen until you
are fairly close to max heap size. The other seems to be based
on idle time.
Combine all of this with immutable objects and gobble
gobble gobble.
And yes, I understand that the current GC is optimized
for a different situation, but it is still a fear that people will
have. It is important that whatever GC is written take into account
the type of environment it is running on. It may be best to have
the GC run very often. It may be better to have it run whenever
new would return an out of memory exception. (It currently doesn't
on real Java.)
In any case, I see it as the single biggest "memory" issue.
>
> What causes Java to gobble memory is more likely (a) the amount of
> header overhead it places on objects (more to do with hashing support
> than gc, I suspect) and (b), to a lesser extent, the fact that objects
> are never "expanded" in place but always pay an additional pointer
> overhead.
Header overhead is very small. Pointer overhead is probably
larger than header overhead in current JVM's because of the indexing,
etc. that goes on. Besides which, some of this hit happens on every
reference collectively making it relatively expensive.
>
> The space overhead for garbage collection per se is quite small, near
> zero if you stop the interpreter during gc and every object has a method
> table; even if you do full traversal (obviating all need for type tags
> if you are clever) the temp space is proportional only to the square
> root of heap size and a couple of marking bits in each pointer (using
> technology 25 years out of date; there may be a better bound by now).
>
> But think about it: a garbage collector can release memory *as soon as
> is logically possible*. This *must* be no worse than an explicit-release
> system. If the gc waits longer, that is a pure - and automatically
> managed - time/space tradeoff.
Agreed. Howver, in a language that encourages the creation
of _many_ throw-away objects a size optimized GC becomes very
important. It may have to be so agressive as to run after every
scope exit.
>
> stephen (who still isn't sanguine about RCX Java but hates to see a
> language attacked for its *good* features)
Ack. Please don't think that I'm attacking Java. As far
as I'm concerned it was the language that I've been waiting for
since I first learned of C++. I only sought to focus the memory
worries where they need to be focused. After you take the class
loader out of the JVM, the single biggest memory waster you are
going to see is an improperly thought out garbage collector.
-Paul (pspeed@progeeks.com)
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
| |
Valid questions, all of them. We do tend to remain in the upper ranks of CS on
this list. I'll see if I can take a stab at defining some terms quickly and
clearly. BTW, I wouldn't mind adding my knowledge of CS to a FAQ for newbies.
Mindstorms will tend to attract people with no programming background, and
this would be a great place for them to come as a reference source just to get
acquainted with the whole programming experience. The "help" from LEGO might
be nice for kids, but even they will want something more than "think like a
computer" to debug your program. How can they think like a computer when they
don't know the basics of how a computer thinks?
A class library is a collection of (ostensibly) related
classes/functions/modules that can (ostensibly) be reused in other programs.
Really, just a way of keeping one's code collected.
function-local variables - (I haven't heard this term exactly before, but I'm
pretty sure I know what it is) - A local variable is a variable that has
limited scope. In other words, the variable only exists and can be accessed by
a small segment of the program, usually a function/method. Local variables are
useful for storing temporary information that the rest of the program doesn't
need to see, but that you need for a given chunk of code to work.
recursion - the process of one function calling itself to solve a problem.
This is done by breaking the problem down to its smallest size, then combining
the smaller solutions. Factorials are usually used as a simple example of
recursion. 6! = 6*5*4*3*2*1. One can repeatedly break the factorial down
until you reach 1, then recombine the problem to find the final solution.
global variables - sort of the opposite of local variables. These variables
are visible to pretty much the entire program and can be read/written from
anywhere. The original Mindstorms language has only global variables.
dynamic memory allocation - Deciding at run-time how much memory is needed for
a given thing (thing being an object, an array, etc). Normal variables are
allocated statically. An int might always take up 32 bits of space. Objects
can be dynamic, as the size required is not always known.
dynamic string allocation - Not many languages really support this. Usually,
strings get a certain amount of space, ie, C++ has you create a character array
of a given size, and that's how big the string can be. Java simulates dynamic
string allocation by creating entirely new String objects each time the string
is changed. I think APL is the only language I know of that has true dynamic
string allocation.
object oriented programming (OOP, or just OO) - a programming paradigm, as
opposed to iterative programming, functional programming, or logic based
programming. In OO, everything is an object. Objects have variables and
operations on those variables. One can move objects around, chain them
together, have them talk to one another. Going much beyond this would require
much more space than I'm willing to devote. Java is a mostly OO language. C++
is a hybrid of OO and iterative and is based on C, which is iterative. LISP is
a functional language, as is Scheme, a LISP derivate. Prolog is a logic
language. There's another term for iterative, but it escapes me right now.
In lugnet.robotics, lego-robotics@crynwr.com (Aa-Tchoo!) writes:
> Hi.
>
> Hope I can jump in here and ask where a newby who knows he's in the deep end • in computer science
> discussions, - knows he's taking in water, coughing and spluttering but • loving every minute of it -
> go to ask elementary questions like:
> What's a class library?
> How do you define function-local variables / recursion / global variables /
> dynamic memory allocation / dymamic string allocation /
> object oriented programming, for Christopher's sake?
> I know this is basic stuff for some and could take up vast yards of bandwidth • but I need to find
> guidance somewhere.
>
> Some teenagers might have got the MindStorms RIS to learn robotics, but I got • it to learn
> programming while having a blast. OK, I'm a doctor, so I'm used to tackling • vast heaps of technical
> definitions and description, but I bet there are others out there who came • here for the same reason.
> I bet we could, in one group or the other, steadily build up a FAQ full of • relevant definitions for
> would-be hackers. Or pointers to sources of reference, preferably on the net. • Any ideas?
>
> Please pardon me if I've overlooked an existing source for this kind of newby • knowledge. I scrolled
> through the whole (awesome) homepage looking.
>
> Thanks for the opportunity to be a fly on the wall at the fascinating • discussion, this last week.
> Regards,
> Ko-LIIN.
|
|
| |
On Sat, 8 May 1999, stephen p spackman wrote:
> You see? Not everyone out there wants or needs a Java. With a properly
> designed language _not one_ of these concepts would need explaining -
> though most of them would fall out as "huh, that's obvious, you need a
> _word_ for that?" concepts.
I have never said that everyone wants or needs Java. I am quite
certain that no single platform of any type will please all of the people
all the time. As I have said repeatedly here, I think choosing Java
minimizes the total work required to get a new bytecode interpreter in
the RCX. Sure, the interpreter is more complex than would otherwise be
required, but then you have most of the design done for you and you have
all the development tools on all the platforms.
> Really, Java is much more complex - and less powerful - than it needs to
> be, just because of the market necessity to be like C++.
I guess it depends on how you define "needs to be". Java wasn't designed
from a merketing decision -- it was originally designed because James
Gosling wanted to put software in consumer devices and decided that
traditional languages didn't fit the bill. It was developed for this
purpose, and only after it was done did the marketing engine take over
and the hype about it being the future of all computing, etc.
> Why can we not be free of this? The impediment is not technical.
I am not sure exactly what it is you want to be free of. If you mean C++
syntax, go use Eiffel, Smalltalk, or Scheme. If you think you have a
better way of doing things, then by all means go do it and tell us when
you are done.
> stephen (who thinks a Java port to the RCX *would* be cool, but who just
> doesn't think it meets the brief of "something simpler and more powerful
> that everyone could enjoy using" - I mean, why not port Emacs lisp ;->)
Simpler for the end user -- you write a 10-line Java class that controls
your robot and download it. You don't have to worry about linking an OS,
you don't have to be constrained by ridiculous limitations like you were
programming in the early BASICs without arrays, etc. At the same time, if
you want to do something more complicated such as build robots which work
together over a network protocol or implement complicated behaviors, then
you can do that too.
I believe the end result will be something that someone can write code in
a very similar fashion to NQC and download that in a manner similar to
the standard firmware and get similar results. At the same time, you can
build a complicated application consisting of multiple classes and link
it together and download it to the same firmware and run it just as well.
I happen to think that would be worthwhile goal that people other than
myself would find useful. If you don't, then go build what you think
will be useful.
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
|
|
| |
Let's move this discussion to lego-robotics-rcx, since that group was
created for discussions like these.
On Sat, 8 May 1999, stephen p spackman wrote:
> Well, dynamic loading, not late binding; this stuff would not be on the
> RCX - presumably almost all of the class loader remains on the host
> machine, with downloaded code pre-linked and pre-verified. You'd be
> truly silly not to split the symbol table - I don't think introspection
> will be heavily used in this environment :-).
Late binding requires the symbol table or some representation of the same
thing. For example, you have C inheriting from B inheriting from A. A
defines f(), but B and C do not. A method in C calling f() must use A.f().
Then B is recompiled and now implements f(). The same code used in C
must now call B.f() without recompiling C.
I am planning on giving up late binding by requiring that all derived
classes be relinked when a parent class is modified.
> Am I wrong? Most systems that provide hashing of mutable objects either
> go to great lengths to ensure that objects never relocate, or actually
> CHOOSE a hash code at object creation and STORE it in the object. Either
> approach requires space overhead: either a pointer somewhere or a hash
> value.
Sun's reference implementation uses a pointer indirection so that objects
can be relocated during GC. That pointer's location never changes, so
they use that as the hash code. If you create your own hashCode() method,
it is a method entry in the class which takes no space in each instance.
If you generate the hash value from the contents of the object rather than
its address, there is no space overhead per instance.
> So it looks to me that the minimum size of java.lang.Object is three
> pointers (the pointer to the object, the vtable, the hash mechanism),
> and measurements suggest it is actually much bigger.
Don't forget the monitor used for synchronization, the pointer to
instance variables, the pointer to the class, etc.
> Nono, that was a space analysis; recall that I was replying to an
> objection that there was no *room* for a gc on the RCX. Of *course*
> there is time overhead in this situation; a time overhead which I
> calculate to be comparable to that of using an interpreter rather than
> compiled code (that is, a small few instructions per "useful"
> instruction).
If you mean only efficiency of when the space can be reused, then GC is still
not best. Explicit freeing of memory can happen at the instant the memory
is no longer required. GC can take place no sooner than that, and generally
will be much later.
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
|
|
| |
In lugnet.robotics, lego-robotics@crynwr.com (John A. Tamplin) writes:
> Let's move this discussion to lego-robotics-rcx, since that group was
> created for discussions like these.
John and several other people are set up with the new group and successfully
posting to it, so this info is for anyone else:
lugnet.robotics.rcx is a newsgroup running on the lugnet.com newsserver and
it is available via e-mail as <lugnet.robotics.rcx@lugnet.com>.
To receive this subgroup via e-mail:
- Visit the LUGNET News-by-Mail settings page:
http://www.lugnet.com/news/mail/
and add the group to your list of LUGNET e-mail subscriptions,
designating any digest options you prefer.
This sets you up to lurk.
To apply for posting privileges (to any/all LUGNET groups, if you haven't
already done so):
- Visit the LUGNET news-posting setup page:
http://www.lugnet.com/news/post/setup/
This allows you to post, and only needs to be done once. Once you are
"in" it automatically applies to all LUGNET groups.
Then to post, simply either
- Address your messages via e-mail to: lugnet.robotics.rcx@lugnet.com
or
- Post your messages directly via NNTP (netnews) using:
NNTPSERVER: lugnet.com
NNTPPORT: 119 (or 8000 or 8080)
or click: news://lugnet.com/lugnet.robotics.rcx
Additional notes:
- You can crosspost to other LUGNET groups by adding them to the
Newsgroups and/or Followup-To headers, for example:
Newsgroups: lugnet.robotics.rcx,lugnet.robotics
Followup-To: lugnet.robotics.rcx
or by addressing your post via e-mail to multiple addresses, for example:
To: lugnet.robotics.rcx@lugnet.com,lugnet.robotics@lugnet.com
Reply-To: lugnet.robotics.rcx@lugnet.com
- LUGNET stands for: the unofficial fan-created LEGO Users Group Network:
http://www.lugnet.com/
http://www.lugnet.com/news/
--Todd
> [big snip]
|
|
|
