Anybody tried to run a Squawk VM on a FPGA (e.g. Xilinx SPARTAN-3E) ?
Message was edited by: lamik06
may i ask, how does your work on "squawk on OS" progress?
like roger, i want to get to run squawk on a controller which comes with a operating system and i'm not quite sure whether it would be better to do a "bare metal" or a "on OS" port.
the controller is the beck-ip sc 143 (a 186 cpu)
Checkout the squawk_native branch, and set the build properties to PLATFORM_TYPE=NATIVE
You will need to add some specialized code for your platform in the builder, cldc, and vmcore modules. Search for the vxworks specialized code for examples.
I'm thinking about how to attach the Squawk VM as a ThreadX task running on an existing Altera ARM9 system.
I'm not yet clear about separating the VM from the underlying hardware resources, and if there is a memory map and drivers that the VM expects to find.
The Theory of Ops is pretty sparse about how all the classes are arranged in the flash, what the bootloader does, and how the class loader finds the classes.
So I think I am not very far along the journey...
Ok, just keep in mind, Sun SPOT is not Squawk. There is no theory of operations for Squawk :(
There is no memory map that Squawk expects, other than what you put in the corevm parts. Oh wait, I think the suite needs to be at address 0
The corevm is responsible for loading the bootstrap suite. You load that into memory however you like. What I am not sure about is at what address the suite needs to be at. I will let Derek answer that one :)
The journey will be somewhat painful as you are just starting out with a project that has not enough documentation put out. Our choice at moment is to help you as best we can and to write code :)
I'm going to step back abit and ask a few questions...
So you''d run Squawk as a task on the ThreadX RTOS? Is it possible/desirable for Squawk to take over handling interrupts, memory mapping, etc?
We currently have two kinds of platforms:
- desktop, with hosted support. This means that squawk uses a desktop Java VM as the "porting layer", getting access to files, sockets, etc via JNI calls. Very wasteful, but very portable as long as you hhave a Java VM on the desktop.
- bare metal. This means that Squawk expects to handle everything. It uses newlib for basic C library operations, but otherwise handles everything itself.
We are starting work (this week!) on running directly on an OS. Initially targeting anything with a POSIX-like interface to files and sockets.
I'm not sure if running on ThreadX is more like running on bare-metal or running directly on an OS. What do you think?
Exactly where I ran out of usable thoughts! Forgive me if I implied that I had some practical use in mind, just thinking about what I have on hand to play with.
Squawk likely would have to give up handling interrupts, unless trap tables could call into exposed native Squawk addresses to respond to interrupts. The VM would be stripped down to a Java interpreter, and rely on a message passing architecture with other ThreadX threads to provide real time services. If the VM wants to provide it's own threading model, all sorts of bad history comes to mind. I don't know anything about how garbage collection would work. I assume that this would limit the appeal of running random Java code, unless their libraries are compatible with the resources. All easier to do on a tightly controlled target..., like a Spot!
(But it would be cool to have a plug-in VM task function and classes that would implement a defined set of features - (JSRs). This could drop into an embedded target and avoid porting in features from scratch using native code. Just my thoughts, probably already done somewhere.)
Sounds a lot like hosted support mode. Running on POSIX sounds about the same. There would have to be the same type of porting layer to provide all the resources that the Java classes expect to find.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.