Wow, you're thinking of doing an on-calc compiler, too? A JVM is kind of feasible, but I can never see an on-calc compiler working alongside it. I wish you the best of luck, but considering how bloated C is to begin with, I doubt this will reach fruition. Stick with a JVM, IMO, and maybe it will work out.
On-calc compiling will be a random thing (cool), but it will be VERY hard to manage the memory... I was thinking at the time to only compile Java bytecode instructions into classes...
I will begin work tomorrow (sat.) on moving over ALL of the global variables in leJOS to SDCC's __at format.
Since leJOS will have to butcher the RAM and play with it beyond repair, I was thinking that the OS should be allowed to start in 2 modes, C or Java. All that will change is what is launched at start, either Launcher or leJOS. They will still use GlassOS's libraries/ROM 0, but the control of the OS will be split (and 2 ISRs for each mode because of the memory layout and needs of each mode).
I will try to get the heap to be either 2 RAM pages/7 RAM pages, the rest in 16KB minus the globals and such. It will be packed, but it should work well. The max program size will be 64KB (sizeof(int) == 2) so it will be a sigh of relief coming from SDCC's sorta-big code size along with the 16KB limit.
Also, can anyone explain the class header (specifically, how the class is able to find other classes for use with get* and invoke*). I am not sure how leJOS does it from the fact that I don't understand sun (they avoided that area of discussion in their JVM notes)
I will begin work tomorrow (sat.) on moving over ALL of the global variables in leJOS to SDCC's __at format.
Since leJOS will have to butcher the RAM and play with it beyond repair, I was thinking that the OS should be allowed to start in 2 modes, C or Java. All that will change is what is launched at start, either Launcher or leJOS. They will still use GlassOS's libraries/ROM 0, but the control of the OS will be split (and 2 ISRs for each mode because of the memory layout and needs of each mode).
I will try to get the heap to be either 2 RAM pages/7 RAM pages, the rest in 16KB minus the globals and such. It will be packed, but it should work well. The max program size will be 64KB (sizeof(int) == 2) so it will be a sigh of relief coming from SDCC's sorta-big code size along with the 16KB limit.
Also, can anyone explain the class header (specifically, how the class is able to find other classes for use with get* and invoke*). I am not sure how leJOS does it from the fact that I don't understand sun (they avoided that area of discussion in their JVM notes)
AHelper wrote:
Also, can anyone explain the class header (specifically, how the class is able to find other classes for use with get* and invoke*). I am not sure how leJOS does it from the fact that I don't understand sun (they avoided that area of discussion in their JVM notes)
C or Java, 'cause there's nothing remotely like any of that in Java.
seana11 wrote:
AHelper wrote:
Also, can anyone explain the class header (specifically, how the class is able to find other classes for use with get* and invoke*). I am not sure how leJOS does it from the fact that I don't understand sun (they avoided that area of discussion in their JVM notes)
C or Java, 'cause there's nothing remotely like any of that in Java.
KermMartian wrote:
seana11 wrote:
AHelper wrote:
Also, can anyone explain the class header (specifically, how the class is able to find other classes for use with get* and invoke*). I am not sure how leJOS does it from the fact that I don't understand sun (they avoided that area of discussion in their JVM notes)
C or Java, 'cause there's nothing remotely like any of that in Java.
Are you referring to C when you say "Class Header" or "get* and invoke*?
Heh, time for overkill...
get* and invoke* are java ops, and the ClassFile is a C struct
From The Java Virtual Machine Specification (sorry, but just have to pull out parts)
It then says that the elements have the layout of
I know that these are used by the get* and invoke* op codes, but I don't know how these structs are stored/used.
get* and invoke* are java ops, and the ClassFile is a C struct
From The Java Virtual Machine Specification (sorry, but just have to pull out parts)
The Java Virtual Machine Specification wrote:
A class file consists of a single ClassFile structure:
Code:
<snip>
constant_pool[]
The constant_pool is a table of structures (§4.4) representing various string constants, class and interface names, field names, and other constants that are referred to within the ClassFile structure and its substructures. The format of each constant_pool table entry is indicated by its first "tag" byte.
The constant_pool table is indexed from 1 to constant_pool_count-1.
Code:
ClassFile {
u4 magic;
u2 minor_version;
u2 major_version;
u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];
u2 access_flags;
u2 this_class;
u2 super_class;
u2 interfaces_count;
u2 interfaces[interfaces_count];
u2 fields_count;
field_info fields[fields_count];
u2 methods_count;
method_info methods[methods_count];
u2 attributes_count;
attribute_info attributes[attributes_count];
}<snip>
constant_pool[]
The constant_pool is a table of structures (§4.4) representing various string constants, class and interface names, field names, and other constants that are referred to within the ClassFile structure and its substructures. The format of each constant_pool table entry is indicated by its first "tag" byte.
The constant_pool table is indexed from 1 to constant_pool_count-1.
It then says that the elements have the layout of
The Java Virtual Machine Specification wrote:
All constant_pool table entries have the following general format:
Code:
but I don't know where §4.4.x structs are at...
Code:
cp_info {
u1 tag;
u1 info[];
}I know that these are used by the get* and invoke* op codes, but I don't know how these structs are stored/used.
Sorry, can't help you here... I've never heard of get* and invoke*, are you sure that they're Java? If so, the are very obscure, and you shouldn't use them if you want readable code.
Sorry Ahelper, I have no idea. I do know, however, that Seana doesn't seem to be getting it. Writing a JVM is very different from just writing Java code. Things you may know about Java don't exactly translate over to C or the requirements of a JVM. If you can provide info about writing a JVM, please do so. If it is just going to be about Java code, then I don't think it will really help Ahelper at all, at least, not until more of the JVM is written.
I do get it.
He says Java... I don't know if it is... Doesn't look like anything I've seen.
Quote:
get* and invoke* are java ops
He says Java... I don't know if it is... Doesn't look like anything I've seen.
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement