notes-computer-jasper-jasperLowEndTargets

Wouldn't it be interesting if Jasper could be a good choice for embedded systems too? This is not one of my main goals, but Lua is inspiring in that it seems it started out just trying to a small, portable, simple, language suitable for embedding into host applications, and it turned out to be suitable for running on low-end hardware too.

Jasper has similar, if different, goals, so maybe we can think about targetting low-end hardware too. Our similar goals are: simplicity; embeddability into host applications, because it's hard to start using a new language if you have to write a project entirely in that language, but easier if you can start by adding new functionality to an existing project in the new language. Unlike Lua, we are not as concerned with performance, however.

Survey of potential low-end hardware targets

PIC AVR ARM Intel Quark

ARM L1 cache

486 had 8K of L1 cache

Rasberry Pi

Uses an ARM1176JZF-S processor, which was also used by the iPod Touch and many smartphones. (Broadcom BCM2835 SoC? with a GPU) at 700Mhz. The ARM1176JZF-S can have L1 cache configured from 4k to 64k.

This book claims that the Pi's L1 instruction cache is 16k and the L1 data cache is 16k.

Intel Quark

Intel Quark SoC? X1000

16 Kbyte shared instruction and data L1 cache.

"The SoC? also features a 512 Kbyte on-die embedded SRAM (eSRAM) that can be configured to overlay regions of DRAM to provide low latency access to critical portions of system memory. For robustness, the contents of this on-die eSRAM are also ECC protected. "

Total memory size from 128 Mbyte to 2 Gbyte

NEST thermostat

ST Microelectronics STM32L151VB ultra-low-power 32 MHz ARM Cortex-M3 MCU -- http://www.ifixit.com/Teardown/Nest+Learning+Thermostat+2nd+Generation+Teardown/13818

Pebble watch

ARM Cortex-M3 processor

Arduino

Arduino Due: "The Due makes use of Atmel's SAM3U ARM-based process, which supports 32-bit instructions and runs at 96Mhz. The Due will have 256KB of Flash, 50KB of SRAM, five SPI buses, two I2C interfaces, five serial ports, 16 12-bit analog inputs and more. This is much more powerful than the current Uno or Mega.". Cortex M3

http://arduino.cc/en/Main/arduinoBoardDue says: 96 KBytes of SRAM. 512 KBytes of Flash memory for code.

Phone baseband processors

" This operating system is stored in firmware, and runs on the baseband processor. As far as I know, this baseband RTOS is always entirely proprietary. For instance, the RTOS inside Qualcomm baseband processors (in this specific case, the MSM6280) is called AMSS, built upon their own proprietary REX kernel, and is made up of 69 concurrent tasks, handling everything from USB to GPS. It runs on an ARMv5 processor. "

Beaglebone

http://beagleboard.org/Products/BeagleBone%20Black

Processor: AM335x 1GHz ARM® Cortex-A8

    512MB DDR3 RAM
    2GB 8-bit eMMC on-board flash storage
    3D graphics accelerator
    NEON floating-point accelerator
    2x PRU 32-bit microcontrollers

Connectivity

    USB client for power & communications
    USB host
    Ethernet
    HDMI
    2x 46 pin headers

Software Compatibility

    Ångström Linux
    Android
    Ubuntu
    Cloud9 IDE on Node.js w/ BoneScript library
    plus much more

The PRU 32-bit MCUs are:

http://elinux.org/Ti_AM33XX_PRUSSv2

8KB program memory

8KB data memory

Cortex M-series

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0321a/BIHEADII.html

" The Cortex-M0, Cortex-M0+, Cortex-M1, Cortex-M3, and Cortex-M4 processors do not have any internal cache memory. However, it is possible for a SoC? design to integrate a system level cache. Note

A small caching component is present in the Cortex-M3 and Cortex-M4 processors to accelerate flash memory accesses during instruction fetches. "

Teensy 3.0

http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a

Technical Specifications:

    32 bit ARM Cortex-M4 48 MHz CPU (M4 = DSP extensions)
    128K Flash Memory, 16K RAM, 2K EEPROM

ATmega1284P

Used in http://reprap.org/wiki/Melzi and i hear ATmega128 referred to often (e.g. search on this page for "ATmega128").

"The high-performance Atmel 8-bit AVR RISC-based microcontroller combines 128KB ISP flash memory with read-while-write capabilities, 4KB EEPROM, 16KB SRAM, 32 general purpose I/O lines, 32 general purpose working registers, a real time counter, three flexible timer/counters with compare modes and PWM, two USARTs, a byte oriented 2-wire serial interface, an 8-channel 10-bit A/D converter with optional differential input stage with programmable gain, programmable watchdog timer with internal oscillator, SPI serial port, a JTAG (IEEE 1149.1 compliant) test interface for on-chip debugging and programming, and six software selectable power saving modes. The device operates between 1.8-5.5 volts.

By executing powerful instructions in a single clock cycle, the device achieves throughputs approaching 1 MIPS per MHz, balancing power consumption and processing speed. " -- http://www.atmel.com/devices/atmega1284p.aspx

Apple I

4K or 8K bytes RAM, expandable to 65K.

Apple II

"...a MOS Technology 6502 microprocessor running at 1 MHz, two game paddles,[9] 4 kB of RAM, an audio cassette interface for loading programs and storing data, and the Integer BASIC programming language built into the ROMs. The video controller displayed 24 lines by 40 columns of monochrome, upper-case-only (the original character set matches ASCII characters 20h to 5Fh) text on the screen, with NTSC composite video output suitable for display on a TV monitor, or on a regular TV set by way of a separate RF modulator. The original retail price of the computer was $1,298 USD[10] (with 4 kB of RAM) and $2,638 USD (with the maximum 48 kB of RAM).[11]"

Apple II Plus

" The Apple II Plus, introduced in June 1979,[20][21][22][23] included the Applesoft BASIC programming language in ROM. This Microsoft-authored dialect of BASIC, which was previously available as an upgrade, supported floating-point arithmetic, and became the standard BASIC dialect on the Apple II series (though it ran at a noticeably slower speed than Steve Wozniak's Integer BASIC).

Except for improved graphics and disk-booting support in the ROM, and the removal of the 2k 6502 assembler/disassembler to make room for the floating point BASIC, the II+ was otherwise identical to the original II. RAM prices fell during 1980–81 and all II+ machines came from the factory with a full 48k of memory already installed. The language card in Slot 0 added another 16k, but it had to be bank switched since the remaining CPU address space was occupied by the ROMs and I/O area. For this reason, the extra RAM in the language card was bank-switched over the machine's built-in ROM, allowing code loaded into the additional memory to be used as if it actually were ROM. Users could thus load Integer BASIC into the language card from disk and switch between the Integer and Applesoft dialects of BASIC with DOS 3.3's INT and FP commands just as if they had the BASIC ROM expansion card. The language card was also required to use the UCSD Pascal and FORTRAN 77 compilers, which were released by Apple at about the same time. These ran under the UCSD p-System operating system, which had its own disk format and emitted code for a "virtual machine" rather than the actual 6502 processor. "

Apple IIe

" The Apple II Plus was followed in 1983 by the Apple IIe, a cost-reduced yet more powerful machine that used newer chips to reduce the component count and add new features, such as the display of upper and lowercase letters and a standard 64 kB of RAM.

The IIe RAM was configured as if it were a 48 kB Apple II Plus with a language card; the machine had no slot 0, but instead had an auxiliary slot that for most practical purposes took the place of slot 3, the most commonly used slot for 80-column cards in the II Plus. "

Random Comments

http://lifehacker.com/how-to-pick-the-right-electronics-board-for-your-diy-pr-742869540

"It really makes zero sense to use an 8 bit uCtlr just about anywhere anymore, when you can get an ARM in the same size package and at nearly the same cost. Since flash dominates the die area in a microcontroller, 8-bit versus 32-bit logic is noise -- it has less cost impact than the package. There are a lot of Cortex-M3 parts in 48 pin packages now that cost only slightly more than 8 bit parts. (I should point out that there is huge difference between, an ARM Cortex-M3 and an ARM-A9, for instance an MMU.)

In the end, it comes down to MIPS and MFLOPS, and the die area and power required to do that much computation. When an ARM has enough functional units to match the MIPS and MFLOPS of an x86, it will take as much die area and power. At the complexity level of a Pentium IV, the added ugliness of the X86 instruction set is pretty much noise in the total die area and power. (In a past life I was an instruction decode and pipeline control logic design specialist -- I can tell you that x86 instruction decode is as ugly as it comes -- and in the day and age of out-of-order execution, that almost doesn't matter, except that because of all that ugliness x86 code is freakishly dense, which means the same size I-cache holds a lot more useful code. When you toss in the fact that the ugliness is also guarantees employment for instruction decode specialists, I'd call that a win :) "

" I use frequently the cheap $9.90 ARM 32 bits LPC2103 board, running at 48MHz, 32KB flash and 8KB RAM: http://www.wayengineer.com/index.php?main_page=product_info&products_id=129 "

" Wow that pdip cortex-m0 is awesome ! It can even run directly from 2 AAA batteries and is debuggable by openocd without ugly kludges. Once it sells on ebay or anywhere with cheap intl shipping, I’m definitely there ! The only shame is it doesn’t have a usb device interface (but you could make a software-based usb low speed device with tons of time to spare). Thanks a lot, hack a day ! "

"

Hussam Al-Hertani says: August 13, 2012 at 10:35 am

There are many ARM Cortex Boards out there. The best (non-arduino clones) in my opinion are the LPCXpresso boards/IDE. The boards cost $20-$30USD, come in many variations, LPC1114(M0)/LPC11U14(M0)/LPC1227(M0)/LPC1343(M3)/LPC1769(M3( with a hardware debugger and a LPCXPresso Developer environment limited to 128KB program size but thats a lot of programming…infact thats more memory than the program memory available on most of the micros on the LPCXpresso boards. The fact that a 28-pin DIP version of the LPC1114 (32KB Flash) micro is available is also nice though I’d like to see a DIP version with more flash memory…at least 64KB. ... The other two boards that have been announced but not produced are the Cortex-m0+ Freedom board from freescale and cortex-m4 Stellaris launchpad. The Cortex-m0+ Freedom board is $13. You get a Dev board (arduino compatible) with debugger. Hopefully they will be compatible with Freescale’s Evaluation version of CodeWarrior? which is limited to 128KB. Again this should mean practically free development cost for the board since the on-board micro has 128KB of memory on it. The last one that (looking real good!) is the $5 Stellaris Launchpad (M4). The board will probably have an on-board debugger and some development tools support via TI’s code composer studio. "

"

peterbjornx says: August 13, 2012 at 2:47 pm

At the moment i’m designing an arduino pin-compatible board based around the TI LM3S817 (Cortex-M3 with 64kB rom and 2kB RAM), which i might also adapt to bigger Stellaris MCU’s "

" My personal favorite 32bit controller is the Maple. But all of my embedded projects have used 8 and 16-bit PICs. My temporarily embedded projects largely use Arduino-ites. "

" I'm writing this comment because I happen to be in the position of working on several projects across many microcontroller lines that have been mentioned in this post – ultra-low-end 8-bit PIC12/16Fs, 32-bit PIC32s, and 32-bit ARMs (mostly Cortex-M0).

Now I know my recent experience with PIC12/16s isn't particularly representative of most hobby 8-bit applications, as PIC16s are pretty crappy architectures in the 8-bit hobby world, which has AVRs (probably one of the highest performance but also most expensive 8-bit chips out there) taking a pretty big market share.

By far the best reason I can give you for switching to 32-bit is simply that they have so many features and perform so fast that they're just easier to work with. The 8-bit project I've been working on is a fairly extensive but also price constrained project with a custom low level infrared protocol decoder, several PWM outputs, and a software instruction decoder. As you can imagine, coding this to work was a b. However, at the sub $1 price point necessary per chip, there wasn't much of an alternative (I hadn't heard of Cortex-M0s / they hadn't come out when we originally spec'd the hardware for the project).

Now I absolutely wished we'd been able to use an ARM. At 48MHz, roughly 1-2 clocks per instructions, 13(!!!!!) PWM outputs, ADCs, 40+ GPIOs, an LPC11xx series does just about everything you wanted with very little work, and virtually no need to worry about not having enough clock cycles. I needed an infrared translator board (still needed processing–implemented a custom serial protocol and the same custom infrared protocol, with some automatic command timing specific to the application) and managed to finish the code literally in two days' worth of free time, compared to about 3-4 weeks for the 8-bit part of the application. No need to be concerned about how I implement passing variables (used good ol' reusable queue structs rather than static queues), using greater than 8-bit variables, etc–I could focus my time on getting my project to work rather than dealing with 8-bit nonsense (16-bit timers on 8-bit micros is a PAIN when buffering isn't available on your chip!)

You can find dev boards at the <$10 range. ... Anyway, to end this, I'm going to link to elm-chan (crazy dude who made his own analog feedback loop to drive a high performance laser projector) and his article on switching from 8-bit to 32-bit Cortex-M0s. It's in Japanese, so you'll have to do a translation, but it's well worth the read as it really matched up pretty well with my experiences and I think many hobbyists' experiences with switching to 32-bit. "

" 8-Bit microcomputer on-board RAM is at most 8 to 16 K bytes, because beyond this RAM is required when 32-bit will be to select a microcontroller. "

LeafLabs Maple

http://leaflabs.com/devices/maple/

Flash Memory: 128 KB SRAM: 20KB

BeagleBoard

JVMs for low-end embedded systems

On PCs, the JVM is known for being relatively memory-hungry, so it's interesting to wonder about how low-end can JVMs go, and how do they do it?

KESO

http://www.embedded.com/electronics-blogs/cole-bin/4389892/KESO--A-Java-VM-an-MCU-developer-could-love--Maybe-

" Unlike traditional JVMs, KESO is designed to operate in tandem with an RTOS, leaving to the RTOS many functions traditional JVMs might take on. For example, it does not implement thread scheduling and thread synchronization, but uses an existing RTOS to do these tasks. As with most Java implementations, it makes selective use of garbage collection, but when it does, it uses a bare-bone, primitive form that assumes operation in a priority-based scheduling environment, another function it lets devolve to the RTOS. Also, rather than depend on the traditional Java VM compiler to generate executable Java code, KESO is provided with a companion compiler called “jino” that generates native C code in an ahead-of-time fashion, making possible a very slim run time environment and fast execution times. ... Rather than just any C code, KESO generates ISO-C90 code, which has a number of advantages. First, because it makes use of a standard C compiler available for most embedded microcontrollers, there is no need for a compiler backend for each target microcontroller. ... In the 8-bit domain, a typical memory configuration is about 8 kilobytes of flash and about 500 to 600 bytes or so of internal SRAM.

The current compiler backend for KESO requires an OSEK/VDK or an AUTOSAR-compatible OS, the most common platforms used in automotive designs. In that environment, KESO takes advantage of the fact that OSEK/VDX is at its core little more than a scheduler based on static priorities. "

TinyVM

"A really low footprint (< 10 Kb) Java VM and replacement firmware for the Lego Mindstorms RCX microcontroller"

http://tinyvm.sourceforge.net/

" TinyVM?'s footprint is about 10 Kb in the RCX. Additionally, program class files are compacted considerably (i.e. resolved) before they are downloaded to the RCX. A small program can access around 16 Kb of RAM. The overhead for each object is 4 bytes, and there is no alignment of fields (e.g. a byte field always requires one byte).

Features of TinyVM? that aren't always found in other RCX programming systems are listed below.

    Great object oriented language (Java)
    Preemptive threads
    Exceptions
    Synchronization
    Arrays, including multidimensional ones
    Recursion
    Access to RCX buttons
    No need to install a cross-compiler
    Fairly easy to install, even under CygWin
    TinyVM's firmware allows itself to be replaced
    Comes with an emulation tool
    Nicely documented APIs 

Since 0.2.0:

    You can rerun a program.
    Full object persistence across runs.
    tinyvm.rcx.Time with sleep() and currentTimeMillis().
    Timers (tinyvm.rcx.Timer).
    Random numbers (java.util.Random).
    LCD characters (tinyvm.rcx.TextLCD). 

Since 0.2.2:

    Auto power off 

Limitations Evidently, it isn't feasible to put a complete Java runtime in 32 Kb, let alone 10 Kb. The most important limitations and missing features of TinyVM? are:

    No garbage collection
    No floating point support
    No switch statements
    String constants are ignored 

Floating point arithmetic and string constants have already been implemented in leJOS, and it's likely that the other limitations will also be addressed there. There are a lot of interesting features that could be added to TinyVM? and/or leJOS, and contributions are always welcome. "

uJ

http://dmitry.gr/index.php?r=05.Projects&proj=12.%20uJ%20-%20a%20micro%20JVM

" The VM size depends on the options selected and the CPU architecture at hand. For example a VM with all options enabled takes up about 80K of codespace on an AVR device, and only 60K on a PIC24 device. To fit into an Atmega64, disabling the "DOUBLE" is all it takes. Of course, if you need double, you can disable something else like "FLOAT" and "LONG" to free up the needed code space. You can also play with optimization options. For example Microchip's "Procedural Abstraction" optimization can reduce the code size by 30%, but at the cost of a 10% decrease in speed. "

" RAM

The VM memory footprint is of utmost importance on a microcontroller, of course. To provide the kind of heap a java VM requires, it is pointless to try and use a normal C-style heap, so uJ implements its own heap manager. This means that your microcontroller need not have an implementation of malloc/free for uJ to work. All uJ memory is allocated in uJ's heap. This makes it very easy to limit uJ to a certain size, or to use the maximum memory that your microcontroller will give you efficiently. All chunks in uJ's heap can be relocated and are referenced by handles. This allows the garbage collector to move memory chunks that are not locked, which is essential when you only have a few kilobytes of RAM. Each heap chunk's header is 2-4 bytes depending on heap size and heap alignment requirements. Each loaded class takes up about 28 bytes (plus any static variables it may have). All objetcs are about 2 bytes more than the sum of the sizes of their instance variables. Each thread takes up about 20 bytes plus stack size (192 bytes by default) plus 3%. Thus even on a small memory footprint it is possible to run reasonably-sized programs. "

" Garbage Collector

The uJ garbage collector is optimized for code size and small heaps. If you give it many megabytes of memory, it will get quite slow - it is not made for such a case. The GC itself is a simple design. Each chunk has a 3-state "mark" field. First we set all of then to zero. Then we walk all the threads' stacks and mark all objects we discover to "1", same for global static variables. Then we loop until no more chunks are left with a "1" mark: find first chunk with a "1" mark, mark it "2", mark all of its children as 1. At the end of this the heap will have objetcs marked "2" and marked "0". All those marked "0" can be freed. Then all unlocked chunks are moved towards the end, so as to make more contigious heap space. Classes are all loaded at the start of the VM, and are non-movable chunks in the end of the heap. Being in the end is how they manage to not fragment the heap space. "

" Strings

As pointed out above, any class can be either native or Java. uJ does not currently support classes that are both, so that leaves us in a pretty unpleasant place regarding the String class. String is the only class in Java that the JVM needs to construct by itself. However, String has a lot of methods that would waste a lot of code space to implement. How do we solve this problem? There is a native class uj.lang.MiniString? that String inherits from. MiniString? implements the most basic things a string does - storing a set of bytes and accessing them. It implements, by default, just three methods - a constructor, XbyteAt?_, and Xlen_, which do exactly what you'd expect them to. The rest of the string class is implemented in Java, including UTF-8 parsing from bytes and all. Yes, indeed this can be slow, so the VM has an option to instead implement length() and charAt in C, significantly speeding those up. Threads

uJ implementes threading, and you can run as many threads as you can fit into RAM. I did not [yet?] implement the entire Thread class, so right now a thread starts immediately when you create a new instance of Thread. This seems fine for me, for now, and I'll work on expanding the thread class soon. Threading introduces synchronization issues, of course, and uJ is ready! The synchronized keyword is fully supported in all possible cases, and functions as expected. Runtime Exceptions

Java has a set of exceptions that the runtime can throw, like NullPointer? and DivideByZero?. uJ could throw those, but that would require you to have a class file for each, wasting 28 bytes of RAM, so instead uJ terminates the runtime and returns the error. This can easily be changed (all the code is there) but I choose not to do this by default. If you want to enable this, it is very easy. "

"

Java class file format is incredibly inefficient to use as is. It was never really meant to be used directly, from what I can tell. It is meant to be loaded into a complex structure in RAM. Needless to say, I haven't got any desire to waste RAM like this - it does not grow on trees. This leaves us with a problem - very inefficient ways of accessing class data (methods, fields, interfaces, etc...). uJ still supports java class files, but it is slow. To solve the problem, at least partially, a different format is used: UJC. UJC stands for "uJ class". Not too creative, I know. What is so special about it?

    Some file-level optimizations
        Unused constants from the original class file are discarded, to avoid empty slots in the constant table, constants are renumbered and the code is adjusted accordingly.
        A table of contents is created for constants, methods, and fields so that the N-th constant can be located in the file without reading the previous N-1.
        Some constants at times refer to other constants, for example nametypeinfo refers to name and type by index. This introduces extra lookups. Such references are replaced with direct offsets, removing the unneeded constant lookups. This places us in a position where we need the constant data for some constants, but they are never referenced by index. We can do that, thanks to the abovementioned constant renumbering - they are stored in the file, but have no index pointing to them.
    Some instruction-level optimizations
        Some constants are moved directly into the code: ldc and ldc2 that load floats or integers are replaced with a custon instruction 0xFE, folowed by the 4 bytes of the constant itself. This significantly speeds up usage of integers > 32767 in java code.
        Static and private method calls to the same class's methods are optimized by finding the index of the method in the class, so that we no longer need to search for it by name. This is impossible for virtual and interface functions, of course. This variant of the invokestatic and invokespecial instructions is encoded using a wide prefix instruction before them.
        Field accesses in the same class (static and instance both) are optimized, replacing the constant index describing the variable with just a type and offset, since it is known already. This variant of the getfield, putfield, getstatic and putstatic instructions is encoded using a wide prefix instruction before them.

So what does this give us? The resulting files are smaller (20% typical) and much faster (depending on the workload, up to 3x) . How do we do all this? The tool I created is called classCvt and it is a rather cool piece of code. It reads the java class file into RAM, with complete understanding of what each chunk of it is. Then it goes over all the code pieces, and breaks them into code blocks. A code block is a piece of code which has a single entry point; that is to say there exist no jumps anywhere else that land you in the middle of this chunk of code. Once we have these blocks, we know for sure that we can freely change their lengths, without disturbing any jumps. We then go over them and modify the instructions as we see fit. We also note which constants from the pool get used, so that we can throw away the ones that aren't and rearrange the rest. After we're done with all the changs, we can reassemble the code back into a single stream. This is not very complex, since, except the first one, the rest of the chunks can be arranged in any order. One possible caveat here: java jumps use 16-bit offsets, so if somehow our changes grow the code size, we can end up in a situation where we cannot fit some jumps into the offset. In this case classCvt will print an error, as expected. "

NanoVM

http://www.harbaum.org/till/nanovm/index.shtml

"What's left? The VM itself is finished. It is not a full Java VM, since it does not support exceptions, threads, floating point arithmetic and various other things like e.g. inheritance from native classes. Due to memory limitations, these things will probably never be implemented for the Asuro and its ATmega8 CPU (keep in mind, that everything has to fit into 8kBytes of code memory). The generic version lacks a complete set of native classes in order to be really useful to the end user. "

"Requires less than 8kBytes of code memory"

" The ATmega8 will very likely be the smallest AVR capable of running the NanoVM?. There's not much memory left in its 8kBytes flash (about 700 bytes are still free), so there isn't space for plenty of generic native classes. With the bigger CPUs (there are AVRs with up to 32 times the code memory of the ATmega8), even the most complex native classes should be possible incl. e.g. networking and wireless support. "

"The low-power Atmel 8-bit AVR RISC-based microcontroller combines 8KB of programmable flash memory, 1KB of SRAM, 512K EEPROM, and a 6 or 8 channel 10-bit A/D converter. The device supports throughput of 16 MIPS at 16 MHz and operates between 2.7-5.5 volts."

http://nanovm.cvs.sourceforge.net/viewvc/nanovm/nanovm/vm/src/opcodes.h?view=markup

" Did you read the restrictions on the JVM you linked? It includes the following problems:

    As little as 512 bytes of program memory (not KB, and definitely not MB)
    As little as 768 bytes of RAM (where your variables go. You're limited to 768 characters of strings by this restriction.)
    About 20k Java opcodes per second on 8 Mhz AVR.
    Only includes java.lang.Object, java.lang.System, java.io.PrintStream, java.lang.StringBuffer, a JVM control class, and a native IO class. You will not be able to do an import java.util.*; and get all the classes not in this list.

If you're not familiar with what these restrictions mean, make sure that you have a plan B if it turns out that you can't actually do the project with Java due to the space and speed restrictions. "

Oracle Java ME Embedded

130 kB of RAM and 350 kB of ROM

http://hackaday.com/2012/10/09/bringing-java-to-the-world-of-microcontrollers/

OneEighty

" OneEighty? released an 8-bit jvm for smartcard app. They're saying they got the footprint down to 55k.

http://www.origin-j.com/products/index.shtml#orij

Which would suck up a little under 50% of the atmega128 program storage resource. "

Java Card on SIM cards

"A typical Java Card device has an 8- or 16-bit CPU running at 3.7MHz, with 1K of RAM and more than 16K of non-volatile memory (EEPROM or flash). High-performance smart cards come with a separate processor and cryptographic chip and memory for encryption, and some come with a 32-bit CPU."

http://www.oracle.com/technetwork/java/javacard/javacard1-139251.html

http://www.ss009.com.ne.kr/

http://www.informatik.uni-augsburg.de/lehrstuehle/swt/se/teaching/fruehere_semester/ws0506/javacard/Dokumentation/JCVMSpec.pdf

https://en.wikipedia.org/wiki/Java_Card

" Java Card vs. Java Language

At the language level, Java Card is a precise subset of Java: all language constructs of Java Card exist in Java and behave identically. This goes to the point that as part of a standard build cycle, a Java Card program is compiled into a Java class file by a Java compiler, without any special option (the class file is post-processed by tools specific to the Java Card platform). However, many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects). Bytecode

Java Card bytecode run by the Java Card Virtual Machine is a functional subset of Java 2 bytecode run by a standard Java Virtual Machine but with a different encoding to optimized for size. A Java Card applet thus typically uses less bytecode than the hypothetical Java applet obtained by compiling the same Java source code. This conserves memory, a necessity in resource constrained devices like smart cards. As a design tradeoff, there is no support for some Java language features (as mentioned above), and size limitations. Techniques exist for overcoming the size limitations, such as dividing the application's code into packages below the 64 KiB? limit. Library and runtime

Standard Java Card class library and runtime support differs a lot from that in Java, and the common subset is minimal. For example, the Java Security Manager class is not supported in Java Card, where security policies are implemented by the Java Card Virtual Machine; and transients (non-persistent, fast RAM variables that can be class members) are supported via a Java Card class library, while they have native language support in Java. Specific features

The Java Card runtime and virtual machine also support features that are specific to the Java Card platform:

Persistence With Java Card, objects are by default stored in persistent memory (RAM is very scarce on smart cards, and it is only used for temporary or security-sensitive objects). The runtime environment as well as the bytecode have therefore been adapted to manage persistent objects. Atomicity As smart cards are externally powered and rely on persistent memory, persistent updates must be atomic. The individual write operations performed by individual bytecode instructions and API methods are therefore guaranteed atomic, and the Java Card Runtime includes a limited transaction mechanism. Applet isolation The Java Card firewall is a mechanism that isolates the different applets present on a card from each other. It also includes a sharing mechanism that allows an applet to explicitly make an object available to other applets.

"

The Java Card Virtual Machine Instruction Set:

aaload aastore aconst_null aload aload_ anewarray areturn arraylength astore astore_ athrow baload bastore bipush bspush checkcast dup dup_x dup2 getfield_<t> getfield_<t>_this getfield_<t>_w getstatic_<t> goto goto_w i2b i2s iadd iaload iand iastore icmp iconst_ idiv if_acmp<cond> if_acmp<cond>_w if_scmp<cond> if_scmp<cond>_w if<cond> if<cond>_w ifnonnull ifnonnull_w ifnull ifnull_w iinc iinc_w iipush iload iload_<n> ilookupswitch imul ineg instanceof invokeinterface invokespecial invokestatic invokevirtual ior irem ireturn ishl ishr istore istore_<n> isub itableswitch iushr ixor jsr new newarray nop pop pop2 putfield_<t> putfield_<t>_this putfield_<t>_w putstatic_<t> ret return s2b s2i sadd saload sand sastore sconst_ sdiv sinc sinc_w sipush sload sload_<n> slookupswitch smul sneg sor srem sreturn sshl sshr sspush sstore sstore_<n> ssub stableswitch sushr swap_x sxor

" A Subset of the Java Virtual Machine 2 This chapter describes the subset of the Java virtual machine and language that is supported in the Java Card 3 platform. 2.1 Why a Subset is Needed It would be ideal if programs for smart cards could be written using all of the Java programming language, but a full implementation of the Java virtual machine is far too large to fit on even the most advanced resource-constrained devices available today. A typical resource-constrained device has on the order of 1.2K of RAM, 16K of non-volatile memory (EEPROM or flash) and 32K-48K of ROM. The code for implementing string manipulation, single and double-precision floating point arithmetic, and thread management would be larger than the ROM space on such a device. Even if it could be made to fit, there would be no space left over for class libraries or application code. RAM resources are also very limited. The only workable option is to implement Java Card technology as a subset of the Java platform. 2.2 Java Card Platform Language Subset Applets written for the Java Card platform are written in the Java programming language. They are compiled using Java compilers. Java Card technology uses a subset of the Java language, and familiarity with the Java platform is required to understand the Java Card platform. The items discussed in this section are not described to the level of a language specification. For complete documentation on the Java programming language, see The Java Language Specification. 2.2.1 Unsupported Items The items listed in this section are elements of the Java programming language and platform that are not supported by the Java Card platform. 2.2.1.1 Unsupported Features The following features are not supported. 2.2.1.1.1 Dynamic Class Loading Dynamic class loading is not supported in the Java Card platform. An implementation of the Java Card platform is not able to load classes dynamically. Classes are either masked into the card during manufacturing or downloaded through an installation process after the card has been issued. Programs executing on the card may only refer to classes that already exist on the card, since there is no way to download classes during the normal execution of application code. 2.2.1.1.2 Security Manager Security management in the Java Card platform differs significantly from that of the Java platform. In the Java platform, there is a Security Manager class (java.lang.SecurityManager?) responsible for implementing security features. In the Java Card platform, language security policies are implemented by the virtual machine. There is no Security Manager class that makes policy decisions on whether to allow operations. 2.2.1.1.3 Finalization Finalization is also not supported. finalize() will not be called automatically by the Java Card virtual machine. 2.2.1.1.4 Threads The Java Card virtual machine does not support multiple threads of control. Programs for the Java Card platform (“Java Card programs”) cannot use class Thread or any of the thread-related keywords in the Java programming language. 2.2.1.1.5 Cloning The Java Card platform does not support cloning of objects. Java Card API class Object does not implement a clone method, and there is no Cloneable interface provided. 2.2.1.1.6 Access Control in Java Packages The Java Card platform language subset supports the package access control defined in the Java language. However, the cases that are not supported are as follows. ■ ■ ■ ■ ■ ■ ■ If a class implements a method with package access visibility, a subclass cannot override the method and change the access visibility of the method to protected or public. A public class cannot contain a public or protected field of type reference to a package-visible class. A public class cannot contain a public or protected method with a return type of type reference to a package-visible class. A public or protected method in a public class cannot contain a formal parameter of type reference to a package-visible class. A package-visible class that is extended by a public class cannot define any public or protected methods or fields. A package-visible interface that is implemented by a public class cannot define any fields. A package-visible interface cannot be extended by an interface with public access visibility. 2.2.1.1.7 Typesafe Enums The Java Card platform language subset does not support the enumerated type facility and the keyword enum. 2.2.1.1.8 Enhanced for Loop The Java Card platform language subset does not support the enhanced for loop language construct. Support for the enhanced for loop construct requires support for array indexing using the integer data type. The Java Card platform only supports array indexing using the short data type. 2.2.1.1.9 Varargs The Java Card platform language subset does not support variable-length argument lists. The variable-length argument construct requires the compiler to generate code that creates a new array object each time a variable-length argument array method is invoked, thereby causing implicit memory allocations in Java Card runtime memory heap. 2.2.1.1.10 Runtime Visible Metadata (Annotations) The Java Card platform does not support this language feature which lets you introduce meta-data information into the runtime environment to be accessed reflectively. The Java Card platform does not support reflection. 2.2.1.1.11 Assertions The Java Card runtime does not provide runtime support for statements in the Java programming language called assertions that are used to test assumptions about program functionality. 2.2.1.2 Unsupported Keywords The following keywords indicate unsupported options related to native methods, threads, floating point, memory management, and debugging. Table 2–1 Unsupported Keywords Unsupported Keywords native strictfp synchronized enum transient assert volatile 2.2.1.3 Unsupported Types The Java Card platform does not support types char, double, float and long. It also does not support arrays of more than one dimension. 2.2.1.4 Unsupported Classes In general, none of the Java programming language core API classes are supported in the Java Card platform. Some classes from the java.lang package are supported (see Section 2.2.2.4, "Supported Classes"), but none of the rest are. For example, classes that are not supported are String, Thread (and all thread-related classes), wrapper classes such as Boolean and Integer, and class Class. 2.2.1.4.1 System Class java.lang.System is not supported. Java Card technology supplies a class javacard.framework.JCSystem, which provides an interface to system behavior. 2.2.2 Supported Items If a language feature is not explicitly described as unsupported, it is part of the supported subset. Notable supported features are described in this section. 2.2.2.1 Supported Features The following features are the more important supported features. 2.2.2.1.1 Packages Software written for the Java Card platform follows the standard rules for the Java platform packages. Java Card API classes are written as Java source files, which include package designations. Package mechanisms are used to identify and control access to classes, static fields and static methods. Except as noted in “Access Control in Java Packages” (Section 2.2.1.1, "Unsupported Features"), packages in the Java Card platform are used exactly the way they are in the Java platform. 2.2.2.1.2 Dynamic Object Creation The Java Card platform programs supports dynamically created objects, both class instances and arrays. This is done, as usual, by using the new operator. Objects are allocated out of the heap. A Java Card virtual machine will not necessarily garbage collect objects. Any object allocated by a virtual machine may continue to exist and consume resources even after it becomes unreachable. Section 2.2.3.2, "Object Deletion Mechanism" for more information regarding support for an optional object deletion mechanism. 2.2.2.1.3 Virtual Methods Since Java Card technology-based objects (“Java Card objects”) are Java programming language objects, invoking virtual methods on objects in a program written for the Java Card platform is exactly the same as in a program written for the Java platform. Inheritance is supported, including the use of the super keyword. 2.2.2.1.4 Interfaces Java Card API classes may define or implement interfaces as in the Java programming language. Invoking methods on interface types works as expected. Type checking and the instanceof operator also work correctly with interfaces. 2.2.2.1.5 Exceptions Java Card programs may define, throw and catch exceptions, as in Java programs. Class Throwable and its relevant subclasses are supported. Some Exception and Error subclasses are omitted, since those exceptions cannot occur in the Java Card platform. Section 2.3.3, "Exceptions" for specification of errors and exceptions. 2.2.2.1.6 Generics This Java language facility allows a type or method to operate on objects of various types while providing compile-time type safety. It adds compile-time type safety and eliminates the need for casting. 2.2.2.1.7 Static Import This Java language facility lets you avoid importing an entire class simply to access its static members or qualifying static members with class names each time it is used. 2.2.2.1.8 Runtime Invisible Metadata (Annotations) This language feature lets you avoid writing boilerplate code under many circumstances by enabling tools to generate it from annotations in the source code. The Java Card platform language subset supports the use of annotations which are not visible at runtime. These annotations do not themselves use the runtime visible meta-data annotation @Retention(RetentionPolicy?.RUNTIME). 2.2.2.2 Supported Keywords The following keywords are supported. Their use is the same as in the Java programming language. able 2–2 Supported Keywords Supported Keywords abstract boolean break byte case catch class continue default do else extends final finally for goto if implements import instanceof int interface new package private protected public return short static super switch this throw throws try void while

2.2.2.3 Supported Types Java programming language types boolean, byte, short, and int are supported. Objects (class instances and single-dimensional arrays) are also supported. Arrays can contain the supported primitive data types, objects, and other arrays. Some Java Card implementations might not support use of the int data type. (Refer to Section 2.2.3.1, "Integer Data Type"). 2.2.2.4 Supported Classes Most of the classes in the java.lang package are not supported on the Java Card platform. The following classes from java.lang are supported on the card in a limited form. 2.2.2.4.1 Object Java Card API classes descend from java.lang.Object, just as in the Java programming language. Most of the methods of Object are not available in the Java Card API, but the class itself exists to provide a root for the class hierarchy. 2.2.2.4.2 Throwable Class Throwable and its subclasses are supported. Most of the methods of Throwable are not available in the Java Card API, but the class itself exists to provide a common ancestor for all exceptions. 2.2.3 Optionally Supported Items This section describes the optional features of the Java Card platform. An optional feature is not required to be supported in a Java Card platform-compatible implementation. However, if an implementation does include support for an optional feature, it must be supported fully, and exactly as specified in this document. 2.2.3.1 Integer Data Type The int keyword and 32-bit integer data type need not be supported in a Java Card implementation. A Java Card virtual machine that does not support the int data type will reject programs which use the int data type or 32-bit intermediate values. The result of an arithmetic expression produced by a Java Card virtual machine must be equal to the result produced by a Java virtual machine, regardless of the input values. A Java Card virtual machine that does not support the int data type must reject expressions that could produce a different result. 2.2.3.2 Object Deletion Mechanism The Java Card 3 platform offers an optional, object deletion mechanism. Applications designed to run on these implementations can use the facility by invoking the appropriate API. See Application Programming Interface, Java Card 3 Platform, v3.0.4, Classic Edition. But, the facility is best suited for updating large objects such as certificates and keys atomically. Therefore, application programmers should conserve on the allocation of objects.

2.2.4 Limitations of the Java Card Virtual Machine The limitations of resource-constrained hardware prevent Java Card virtual machines from supporting the full range of functionality of certain Java platform features. The features in question are supported, but a particular virtual machine may limit the range of operation to less than that of the Java platform. To ensure a level of portability for application code, this section establishes a minimum required level for partial support of these language features. The limitations here are listed as maximums from the application programmer’s perspective. Java packages that do not violate these maximum values can be converted into Java Card technology-based CAP files (“Java Card CAP files”), and will be portable across all Java Card implementations. From the Java Card virtual machine implementer’s perspective, each maximum listed indicates a minimum level of support that will allow portability of applets. 2.2.4.1 Limitations of Packages The following are limitations of packages. 2.2.4.1.1 Package References A package can reference at most 128 other packages. 2.2.4.1.2 Package Name The fully qualified name of a package may contain a maximum of 255 characters. The package name size is further limited if it contains one or more characters which, when represented in UTF-8 format, requires multiple bytes. 2.2.4.2 Limitations of Classes The following are limitations of classes. 2.2.4.2.1 Classes in a Package A package can contain at most 255 classes and interfaces. 2.2.4.2.2 Interfaces A class can implement at most 15 interfaces, including interfaces implemented by superclasses. An interface can inherit from at most 14 superinterfaces. 2.2.4.2.3 Static Fields A class in an applet package can have at most 256 public or protected static non-final fields. A class in a library package can have at most 255 public or protected static non-final fields. There is no limit on the number of static final fields (constants) declared in a class. 2.2.4.2.4 Static Methods A class in an applet package can have at most 256 public or protected static methods. A class in a library package can have at most 255 public or protected static methods. 2.2.4.3 Limitations of Objects The following are limitations of objects. 2.2.4.3.1 Methods A class can implement a maximum of 128 public or protected instance methods, and a maximum of 128 instance methods with package visibility. These limits include inherited methods. 2.2.4.3.2 Class Instances Class instances can contain a maximum of 255 fields, where an int data type is counted as occupying two fields. These limits include inherited fields.

2.2.4.3.3 Arrays Arrays can hold a maximum of 32767 components. 2.2.4.4 Limitations of Methods The maximum number of variables that can be used in a method is 255. This limit includes local variables, method parameters, and, in the case of an instance method invocation, a reference to the object on which the instance method is being invoked (meaning, this). An int data type is counted as occupying two local variables. A method can have at most 32767 Java Card virtual machine bytecodes. The number of Java Card technology-based bytecodes (“Java Card bytecodes”) may differ from the number of Java bytecodes in the Java virtual machine implementation of that method. The maximum depth of an operand stack associated with a method is 255 16-bit cells. 2.2.4.5 Limitations of Switch Statements The format of the Java Card virtual machine switch instructions limits switch statements to a maximum of 65536 cases. This limit is far greater than the limit imposed by the maximum size of methods (Section 2.2.4.4, "Limitations of Methods"). 2.2.4.6 Limitations of Class Initialization The Java Card virtual machine contains limited support for class initialization because there is no general mechanism for executing <clinit> methods. Support for <clinit> methods is limited to the initialization of static field values with the following constraints: ■ ■ ■ Static fields of applet packages may only be initialized to primitive compile-time constant values, or arrays of primitive compile-time constants. Static fields of user libraries may only be initialized to primitive compile-time constant values. Only static fields declared in the current class may be initialized in the <clinit> method. Primitive constant data types include boolean, byte, short, and int. Given Java technology source files that adhere to these language-level constraints on static field initialization, it is expected that reasonable Java compilers will: ■ ■ Inline constants in the bytecodes that reference static final primitive fields that are initialized in the declaration statement. Produce only the following bytecodes: ■ load a value on the stack: iconst_[m1,0-5], [b

aconst_null ■ create an array: newarray([byte■ duplicate items on the stack: dup ■ store values in arrays or static fields: [b■ return from method: return
s]ipush, ldc, ldc_w,
shortbooleanint] )
is]astore, putstatic

2.3.1 Class File Subset The operation of the Java Card virtual machine can be defined in terms of standard Java platform class files. Since the Java Card virtual machine supports only a subset of the behavior of the Java virtual machine, it also supports only a subset of the standard class file format. 2.3.1.1 Not Supported in Class Files The following items are not supported in class files. 2.3.1.1.1 Class Access Flags In class_info and interface_info structures, the access flag ACC_ENUM is not supported. 2.3.1.1.2 Field Descriptors Field descriptors may not contain BaseType? characters C, D, F or J. ArrayType? descriptors for arrays of more than one dimension may not be used. 2.3.1.1.3 Constant Pool Constant pool table entries with the following tag values are not supported. Table 2–3 Unsupported Java Constant Pool Tags Constant Type Value CONSTANT_String 8 CONSTANT_Float 4 CONSTANT_Long 5 CONSTANT_Double 6 2.3.1.1.4 Fields In field_info structures, the access flags ACC_VOLATILE, ACC_ TRANSIENT and ACC_ENUM are not supported. 2.3.1.1.5 Methods In method_info structures, the access flags ACC_SYNCHRONIZED, ACC_STRICT, ACC_NATIVE, and ACC_VARARGS are not supported. 2.3.1.2 Supported in Class Files The following items are supported in class files. 2.3.1.2.1 ClassFile? All items in the ClassFile? structure are supported. 2.3.1.2.2 Field Descriptors Field descriptors may contain BaseType? characters B, I, S and Z, as well as any ObjectType?. ArrayType? descriptors for arrays of a single dimension may also be used. 2.3.1.2.3 Method Descriptors All forms of method descriptors are supported. 2.3.1.2.4 Constant Pool Constant pool table entry with the following tag values are supported.

able 2–4 Supported Java Constant Pool Tags Constant Type Value CONSTANT_Class 7 CONSTANT_Fieldref 9 CONSTANT_Methodref 10 CONSTANT_InterfaceMethodref? 11 CONSTANT_Integer 3 CONSTANT_NameAndType? 12 CONSTANT_Utf8 1 2.3.1.2.5 Fields In field_info structures, the supported access flags are ACC_ PUBLIC, ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC and ACC_FINAL. The remaining components of field_info structures are fully supported. 2.3.1.2.6 Methods In method_info structures, the supported access flags are ACC_ PUBLIC, ACC_PRIVATE, ACC_PROTECTED, ACC_STATIC, ACC_FINAL and ACC_ ABSTRACT. The remaining components of method_info structures are fully supported. 2.3.1.2.7 Attributes The attribute_info structure is supported. The Code, ConstantValue?, Exceptions, LocalVariableTable?, Synthetic, InnerClasses?, RuntimeInvisibleAnnotations?, RuntimeInvisibleParameterAnnotations? and Deprecated attributes are supported. 2.3.2 Bytecode Subset The following sections detail the bytecodes that are either supported or unsupported in the Java Card platform. For more details, refer to Chapter 7, "Java Card Virtual Machine Instruction Set." 2.3.2.1 Unsupported Bytecodes Table 2–5 Unsupported Bytecodes Unsupported Bytecodes lconst_<l> lload fload_<n> daload dstore lastore ladd fsub dmul lrem fneg lushr i2l l2f d2i lcmp dcmpg monitorenter jsr_w fconst_<f> fload dload_<n> caload lstore_<n> fastore fadd dsub ldiv frem dneg land i2f l2d d2l fcmpl lreturn monitorexit dconst_<d> dload laload lstore fstore_<n> dastore dadd lmul fdiv drem lshl lor i2d f2i d2f fcmpg freturn multianewarray ldc2_w2 lload_<n> faload fstore dstore_<n> castore lsub fmul ddiv lneg lshr lxor l2i f2d i2c dcmpl dreturn goto_w

Supported Bytecodes nop sipush aload aaload astore aastore pop2 dup2 iadd irem ishr iinc ificmp_<cond> ret areturn getfield invokestatic anewarray instanceof aconst_null ldc iload_<n> baload istore_<n> bastore dup dup2_x1 isub ineg iushr i2b ifacmp_<cond> tableswitch return putfield invokeinterface arraylength wide iconst_ ldc_w aload_<n> saload astore_<n> sastore dup_x1 dup2_x2 imul ior iand i2s goto lookupswitch getstatic invokevirtual new athrow ifnull bipush iload iaload istore iastore pop dup_x2 swap idiv ishl ixor if<cond> jsr ireturn putstatic invokespecial newarray checkcast ifnonnull

2.3.2.3 Static Restrictions on Bytecodes A class file must conform to the following restrictions on the static form of bytecodes. 2.3.2.3.1 ldc, ldc_w The ldc and ldc_w bytecodes can only be used to load integer constants. The constant pool entry at index must be a CONSTANT_Integer entry. If a program contains an ldc or ldc_w instruction that is used to load an integer value less than -32768 or greater than 32767, that program will require the optional int instructions (Section 2.2.3.1, "Integer Data Type"). 2.3.2.3.2 lookupswitch The value of the npairs operand must be less than 65536. This limit is far greater than the limit imposed by the maximum size of methods (Section 2.2.4.4, "Limitations of Methods"). If a program contains a lookupswitch instruction that uses keys of type int, that program will require the optional int instructions (Section 2.2.3.1, "Integer Data Type"). Otherwise, key values must be in the range -32768 to 32767. 2.3.2.3.3 tableswitch The bytecode can contain at most 65536 cases. This limit is far greater than the limit imposed by the maximum size of methods (Section 2.2.4.4, "Limitations of Methods"). If a program does not use the optional int instructions (Section 2.2.3.1, "Integer Data Type"), the values of the high and low operands must both be at least -32768 and at most 32767. 2.3.2.3.4 wide The wide bytecode can only be used with an iinc instruction. 2.3.3 Exceptions The Java Card platform provides full support for the Java platform’s exception mechanism. Users can define, throw and catch exceptions just as in the Java platform. The Java Card platform also makes use of the exceptions and errors defined in The Java Language Specification. An updated list of the Java platform’s exceptions is provided in the JDK software documentation. Not all of the Java platform’s exceptions are supported in the Java Card platform. Exceptions related to unsupported features are naturally not supported. Class loader exceptions (the bulk of the checked exceptions) are not supported. Note that some exceptions may be supported to the extent that their error conditions are detected correctly, but classes for those exceptions will not necessarily be present in the API. The supported subset is described in the tables below. 2.3.3.1 Uncaught and Uncatchable Exceptions In the Java platform, uncaught exceptions and errors will cause the virtual machine’s current thread to exit. As the Java Card virtual machine is single-threaded, uncaught exceptions or errors will cause the virtual machine to halt. Further response to uncaught exceptions or errors after halting the virtual machine is an implementation-specific policy, and is not mandated in this document. Some error conditions are known to be unrecoverable at the time they are thrown. Throwing a runtime exception or error that cannot be caught will also cause the virtual machine to halt. As with uncaught exceptions, implementations may take further responses after halting the virtual machine. Uncatchable exceptions and errors which are supported by the Java Card platform may not be reflected in the Java Card API, though the Java Card platform will correctly detect the error condition. .3.3.2 Checked Exceptions Table 2–7 Support of Java Checked Exceptions Exception Supported or Not Supported ClassNotFoundException? Not Supported CloneNotSupportedException? Not Supported IllegalAccessException? Not Supported InstantiationException? Not Supported InterruptedException? Not Supported NoSuchFieldException? Not Supported NoSuchMethodException? Not Supported 2.3.3.3 Runtime Exceptions Table 2–8 Support of Java Runtime Exceptions Runtime Exception Supported or Not Supported ArithmeticException? Supported ArrayStoreException? Supported ClassCastException? Supported IllegalArgumentException? Not Supported IllegalThreadStateException? Not Supported NumberFormatException? Not Supported IllegalMonitorStateException? Not Supported IllegalStateException? Not Supported IndexOutOfBoundsException? Supported ArrayIndexOutOfBoundsException? Supported StringIndexOutOfBoundsException? Not Supported NegativeArraySizeException? Supported NullPointerException? Supported SecurityException? Supported 2.3.3.4 Errors Table 2–9 Support of Java Errors Error Supported or Not Supported AssertionError? Not Supported LinkageError? Supported ClassCircularityError? Supported Table 2–9 (Cont.) Support of Java Errors Error Supported or Not Supported ClassFormatError? Supported ExceptionInInitializerError? Supported IncompatibleClassChangeError? Supported AbstractMethodError? Supported IllegalAccessError? Supported InstantiationError? Supported NoSuchFieldError? Supported NoSuchMethodError? Supported NoClassDefFoundError? Supported UnsatisfiedLinkError? Supported VerifyError? Supported ThreadDeath? Not Supported VirtualMachineError? Supported InternalError? Supported OutOfMemoryError? Supported StackOverflowError? Supported UnknownError? Supported UnsupportedClassVersionError? Supported

" There was a great Defcon talk about this called The Secret Life of SIM Cards that I can recommend watching (they release the video for these some time after the conference).

The talk itself was about a group that had an enormous camping trip (I hope that phrasing doesn't diminunise it) called Toorcamp of a few thousand people that thought it would be fun to also put together their own cell network for just them. They bought and programmed SIM cards and hid puzzles in the programs on them.

But the amount of programming that can be done on the SIM card alone without involving the main processor at all was really quite fascinating and there's a lot of detail in the talk if you can track it down. Here are the slides at least https://speakerdeck.com/codebutler/the-secret-life-of-sim-ca...

reply

btown 2 days ago

link

The project website is http://simhacks.github.io/ - and it looks like you can still purchase all the necessary equipment!

reply

xacaxulu 2 days ago

link

That's a really cool link. Easily one of the more interesting things I've read in a while, thanks!

reply

ersii 2 days ago

link

I would also suggest watching Karsten Nohl/SRLabs security research into JavaCard? and the "state of the SIM" from the Observe Make Hack 2013 camping conference, which is available at: https://archive.org/details/D4T204201301031400SimCardExploit... and his article at https://srlabs.de/rooting-sim-cards/

reply "

" If you have an AMEX "Blue" card, then you have a JVM in your pocket (I believe its an Hitachi H8, but one of the tiny 8 bit versions).

About half of all smartcards made right now (including almost all from European giant GemPlus?) run JVMs.

Anyone who went to Sun's JavaOne? show a couple of years ago was handed a rather chunky ring, which had a Dallas Semiconductor iButton on it - this too has a JVM (I actually wrote some code for mine - using the same toolchain as for regular desktop java). I believe it is an 8051 microcontroller. "

Mika VM

https://en.wikipedia.org/wiki/Mika_VM

" This results in a smaller footprint, with non-AWT versions requiring less than 2 MB of persistent storage. Supported operating systems are Linux and uClinux (a proof-of-concept port to eCos has also been made), and supported architectures include x86, arm, mips, and powerpc, including non-MMU variants where applicable. In principle it should be possible to build Mika for any 32-bit CPU for which a GNU toolchain is available. "

MicroEJ

http://www.eetimes.com/document.asp?doc_id=1317511

" MicroEJ? provides a runtime Java platform that includes IS2T’s MicroJvm?, 28 Kbyte Java virtual machine, an optional RTOS (~10 Kbytes), all necessary libraries to run an advanced graphical human-machine interface (HMI), and a fully functional simulated platform that allows fully debugged and tested binary code to be ported directly to any supported MCU. The company’s MicroJvm? Java virtual machine requires only 28 Kbytes of flash, less than 1.5 Kbytes RAM, and has a boot time of just 2 ms at 120 MHz. A fully functional, advanced graphical HMI requires from 90 Kbytes to 140 Kbytes of memory program in total. "

" Easy interface to Legacy C C/ASM drivers and application logic from existing applications can incorporate easily the MicroEJ? JPF platform and make accessible the new Java code while keeping legacy C code. SNI native interface library allows direct calls to C functions from Java, and allows Java methods to be called from C, including arguments of base-types such as integer or float, and arrays. SNI allows sharing of data between both worlds in a very efficient way that avoids intermediate buffers and wasteful buffer copies (note that DMA devices can also share data using a single buffer implementation). "

Bajos, BAJVM

"

Features and limits of BAJOS

BAJOS contains a byte code interpreter, exception handling, multithreading and the java synchronization mechanism, a garbage collected heap, a priority based scheduler and a native code interface. One of the newest features is support of realtime interrupts and handling in java in special threads, which could be created by the user!

Currently BAJOS is based or better “inspired” on the JVM-specification with some limits. Known differences are:

    no long data type
    no double data type
    no unicode support
    no full run time evaluation of all class/method/field-attributes
    no complete exception handling
    less than 256 classes/methods/local variables in methods
    less than 16 kwords (32 bit) on heap
    Array objects have no type information
    No typechecking in the bytecode handlers for ASTORE
    RETURN throws no IllegalMonitorStateException
    String constants are not automatically embedded in a java.lang.String object. If you encounter problems for example with casting String constants, try ‘new String(“STRINGCONSTANT”)’ instead of ‘“STRINGCONSTANT”’
    No Serialization, no java.lang.Serializable
    No hashCode() methods
    No System properties
    No java.lang.Class, no getClass() methods
    No java.lang.NumberFormatException, it is replaced by java.lang.IllegalArgumentException
    No class java.lang.Number and no shortValue, floatValue, byteValue, longValue methods in subclasses.
    No java.lang.Comparable, no compareTo() methods 

The amount of used boot- and system-classes and the complexity of exception handling must be adapted on the available memory space on your target system. Java software can be developed with these limits on a PC and compiled with javac. Classfiles compiled on external machines can be included. "

" Bajos has been tested yet at:

    32 Bit and 64 Bit PC-linux systems (most development and testing is carried out here)
    MICA2 Board (mote) with atmega128 only equipped with internal 4K Byte data ram"

" The Arduino Mega (with the atmega1280 processor 128KB flash, 8 KB data ram) or Mega256 (with the atmega256 processor 256KB flash, 16 KB data ram) is well suitable for Bajos. "

SimpleRTJ

simple Real-Time-Java "requires on average about 18-24KB of code memory"

http://www.rtjcom.com/main.php?p=home

" The simpleRTJ includes all of the core features expected from any virtual machine like multi threading, exception handling, interfaces and the garbage collection. On top of this the simpleRTJ doesn't require any support from the underlying RTOS. In fact, it can be considered as a mini Java OS that can run on its own as it has built in support for the memory allocation, heap management, multi-threading, software timers, etc. "

" Limitations 64-bit data types (long, double) are not supported. Support for the java.lang.Class object is not provided. The symbolic references required by the Class object are removed during the Java application link phase. Not all of standard java packages are included. As simpleRTJ will usually run on embedded systems with limited resources only essential packages/classes are included. Additional packages can be added when required. JNI is not supported due to its complexity and runtime overhead. A simple and fast native interface is provided instead "

"

Processor Compiler Code RO data RW data 68HC11 IAR 17K 1K 0.1K H8/300 GNU GCC 19K 2K 0.2K i186 Borland 5.1 24K 2K 0.2K i386 Borland 5.1 17K 2K 0.2K 68K GNU GCC 18K 2K 0.2K 8051 Tasking 35K 1K 0.1K M.CORE GNU GCC 15K 2K 0.2K AT91R40008 (thumb mode) ARM Devel. Suite 12K 2K 0.2K 68HC16 Cosmic 17K 2K 0.2K "

HaikuVM

http://haiku-vm.sourceforge.net/

"HaikuVM? is so small that it even runs on an atmega8 (and the ASURO robot)."

FemtoJava

http://gse.ufsc.br/~bezerra/disciplinas/SistEmbarcados/Java/FemtoJavaIEEE.pdf

" The FemtoJava? microcontroller can run only class code because its instruction set includes only invokestatic, return, and ireturn as method instructions. However, this is not a serious limitation because it is not necessary for most embedded software to allocate complex objects at runtime. "

" Memory organization Frame allocation plays an important role for the Java program’s execution compatibility, since several instructions (such as load and store) use the current frame as a base to calcu- late the correct target addresses. In such cases, FemtoJava? implements a Java-compatible frame allocation scheme, as shown in Figure 1. Compared to that of processors such as PicoJava?, the FemtoJava? frame allocation is much simpler. In Figure 1, the JVM model only specifies that stack operands must be kept on top of the frame information allocated over local variables’ space. Because we designed FemtoJava? for single-threaded applications and static linked code (with merged method vectors and constant pools), we don’t need to store as many fields on frame information as PicoJava? does. We simply remove the information on monitors, method vectors, and constant pool. "

" FemtoJava? instruction set. Instruction type Mnemonics Arithmetic and logic iadd, isub, imul, ineg, ishr, ishl, iushr, iand, ior, and ixor

Control flow goto, ifeq, ifne, iflt, ifge, ifgt, ifle, if_icmpeq, if_icmpne, if_icmplt, if_icmpge, if_icmpgt, if_icmple, return, ir eturn, and invokestatic

Stack iconst_m1, iconst_0, iconst_1, iconst_2, iconst_3, iconst_4, iconst_5, bipush, pop, pop2, dup, dup_x1, dup_x2, dup2, dup2_x1, and swap

Load/store iload, iload_0, iload_1, iload_2, iload_3, istore, istore_0, istore_1, istore_2, and istore_3

Array iaload, baload, caload, saload, iastore, bastore, castore, sastore, and arraylength

Extended load_idx, store_idx, and sleep

Others nop, iinc, getstatic, putstatic "

Random comments

" The following a Java VMs target embedded systems:

    JamaicaVm (Commercial)
    MicroJVM (Comercial)
    Aonix Perc (Commercial)
    PreonVm (Commercial)
    AvianVM (Open source)
    Open Mika (Open source)
    Squawk (Open source)
    SimplRJT (Open source needs no RTOS for threading support)
    Kaffe (Open source)." -- links at http://stackoverflow.com/questions/10856437/embedded-java-vm-for-cortex-m3

kaffe paper: http://www.eetindia.co.in/ARTICLES/1998FEB/PDF/EEIOL_1998FEB01_EMS_INTD_TA.pdf

"Why not? There are JVMs that run in 64KB of RAM." -- http://hackaday.com/2012/10/09/bringing-java-to-the-world-of-microcontrollers/#comment-812459

" Our IntelliBrain? robotic controller that mainly sells to schools and universities is based on an ATmega128 ( http://www.ridgesoft.com/ )

The VM takes about 60Kbytes of flash including the run-time library, things such as networking are not included as there is no network hardware.

You are correct in that JIT compilation is not appropriate and so the VM interprets the bytecode in real-time. It also has external memory for storage of the bytecode and Java stack. "

" VM is supposedly 70k, supports multi-threading and GC. No graphics capability however. I wonder how big the Palm KVM is at? It includes a small implementation with graphics.

Compatible with Java 1.3 as far as class file format goes. Supposedly runs can interpret any Java bytecode. "

LuaVMs for low-end embedded systems

http://www.eluaproject.net/

" It's hard to give a precise answer to this, because this is not only dependable on the footprint of eLua or it's resource requirements but on the final user applications as well. As a general rule, for a 32-bit CPU, we recommend at least 256k of Flash and at least 64k of RAM. However, this isn't a strict requirement. A stripped down, integer-only version of eLua can definitely fit in 128k of Flash and depending on your type of application, 32k of RAM might prove just fine. We have built eLua for targets with less than 10K RAM but you can't do much than blinking an LED with them. It really largely depends on your needs. "

" eLua is not a stripped down set of Lua to fit in the embedded environment. Much on the contrary, it strives to offer the same features as the desktop version of Lua, complementing them with specific features for embedded use and discarting the need of an operating system running on the microcontrollers. Besides offering different flavors of the full Lua implementation (like the possibility of choosing between an integer-only and a floating point numbers implementation), a lot of work was and will be done in the direction of making Lua more "embedded-friendly" by augmenting the core language with features that allow lower memory requirements and faster embedded performance. "

Python VMs for low-end embedded systems

http://code.google.com/p/python-on-a-chip/

" Requires roughly 55 KB program memory Initializes in 4KB RAM; print "hello world" needs 5KB; 8KB is the minimum recommended RAM. Supports integers, floats, tuples, lists, dicts, functions, modules, classes, generators, decorators and closures Supports 25 of 29 keywords and 89 of 112 bytecodes from Python 2.6 Can run multiple stackless green threads (round-robin) Has a mark-sweep garbage collector Has a hosted interactive prompt for live coding Licensed under the GNU GPL ver. 2

The PyMite? VM DOES NOT HAVE:

    A built-in compiler
    Any of Python's libraries (no batteries included)
    A ready-to-go solution for the beginner (you need to know C and how to work with microcontrollers) "

" Does the PyMite? VM have a GIL?

No. "

"

Keywords ~~~~~~~~

PyMite? supports the following subset of Python's keywords::

and assert break class continue def del elif else for from global if import in is lambda not or pass print raise return while yield

PyMite? DOES NOT support these keywords::

except exec finally try

"

" PyMite? DOES NOT support Long or Complex numbers "

"

"

" PyMite? supports Dictionaries having up to 32767 key, value pairs. "

" PyMite? DOES NOT support overriding type operators using the special forms of identifiers. For example, ``__add__()`` WILL NOT implement or override the ``+`` operator. "

"

Library Modules


PyMite? DOES NOT offer any of the library modules from Python. Instead, PyMite? offers its own set of library modules, some of which have the same name as a module name from Python.

PyMite? offers the following library modules::

dict func list string sys

Idiom Hints


PyMite? does NOT support the idiom ``if __name__ == "__main__":``, instead this should be used: ``if ismain():`` where the ``ismain()`` function is part of the builtins module. "

bytecode interpreter:

http://code.google.com/p/python-on-a-chip/source/browse/src/vm/interp.c

.NET VMs for low-end embedded systems

" The .NET Micro Framework (NETMF) is an open source .NET platform for resource-constrained devices with at least 256 KBytes of flash and 64 KBytes of RAM . It includes a small version of the .NET CLR and supports development in C#, Visual Basic .NET, and debugging (in an emulator or on hardware) using Microsoft Visual Studio. NETMF features a subset of the .NET base class libraries (about 70 classes with about 420 methods), an implementation of Windows Communication Foundation (WCF), a GUI framework loosely based on Windows Presentation Foundation (WPF), and a Web Services stack based on SOAP and WSDL. NETMF also features additional libraries specific to embedded applications "

Fourth for low-end embedded systems

"Bernard Hodson.. has a Forth interpreter and a library of subroutines that occupies less than 32K"

Languages just for low-end embedding

http://www.clifford.at/embedvm/

"The VM itself takes up about 3kB of program memory on an AVR microcontroller. "

" EmbedVM? is a small embeddable virtual machine for microcontrollers with a C-like language frontend "

" The VM simulates a 16bit CPU that can access up to 64kB of memory. It can only operate on 16bit values and arrays of 16bit and 8bit values. There is no support for complex data structures (struct, objects, etc.). A function can have a maximum of 32 local variables and 32 arguments.

Besides the memory for the VM, a small structure holding the VM state and the reasonable amount of memory the EmbedVM? functions need on the stack there are no additional memory requirements for the VM. Especially the VM does not depend on any dymaic memory management.

EmbedVM? is optimized for size and simplicity, not execution speed. ...On an AVR ATmega168 running at 16MHz the VM can execute about 75 VM instructions per millisecond.

All memory accesses done by the VM are parformed using user callback functions. So it is possible to have some or all of the VM memory on external memory devices, flash memory, etc. or "memory-map" hardware functions to the VM. "

http://svn.clifford.at/embedvm/trunk/README.VM

"

Address space and word width


The machine can address up to 64k of memory. The memory can be addressed in units of single bytes, but local variables are always 16bit words.

It operates on 16bit words and are always interpreted as signed integers in contexts where signed/unsigned does make a difference (multiply/divide and the compare operators).

The memory is always accessed using reader/writer functions that are provided by the host environment.

All 16bit memory operations are performed in big endian byte order.

Machine State


The machine state itself is managed using three state variables:

IP (Instruction Pointer) The address of the next instruction to execute

SP (Stack Pointer) The address of the last pushed word on the stack.

SFP (Stack Frame Pointer) The address of the first local variable on the stack.

In addition to that there are three function pointers in the machine state for embedding the VM in a host environment: a reader and a writer for accessing the VM memory and a callback for calling user functions.

The Stack


The stack grows from high address to low addresses.

Each local variable is accessed using an SFA (Stack Frame Address). The address of a local variable is:

          SFA >= 0  ?  SFP - 2*SFA - 2 :  SFP - 2*SFA + 2

There is a maximum of 32 local variables in a stack frame and 32 arguments to a function (arguments have negative SFA).

Calculations are done in a stackmachine like manner (each operation pops its operands from the stack and pushes the result).

The return address for the current function is stored in the 16-bit word on SFP + 2 and the parent stack frame pointer at SFP + 4.

All variables on the stack must be aligned on even addresses. So the stack pointer must be initialized to an even address (LSB not set).

Instruction Encoding


Most instructions fit in a single byte. Some have a 1 or 2 bytes argument. Some instructions push and/or pop values to/from the stack. Not all of the instructions are actually used by the compiler.

+-------------------------------+----------------------------------------+----+

+---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+ +---+---+---+---+---+---+---+---+----------------------------------------+----+
MSB LSB Instruction Off
00SFA Push local variable to stack 00
01SFA Pop local variable from stack 40
10000 .. 0x0Add (pop 2, push 1)80
10001 .. 0x1Sub (pop 2, push 1)
10002 .. 0x2Mul (pop 2, push 1)
10003 .. 0x3Div (pop 2, push 1)
10004 .. 0x4Mod (pop 2, push 1)
10005 .. 0x5Shift Left (pop 2, push 1)
10006 .. 0x6Shift Right (pop 2, push 1)
10007 .. 0x7Bitwise AND (pop 2, push 1)
10008 .. 0x8Bitwise OR (pop 2, push 1)
10009 .. 0x9Bitwise XOR (pop 2, push 1)
100010 .. 0xa Logic AND (pop 2, push 1)
100011 .. 0xb Logic OR (pop 2, push 1)
100012 .. 0xc Bitwise NOT (pop 1, push 1)
100013 .. 0xd Arithmetic invert (pop 1, push 1)
100014 .. 0xe Logic NOT (pop 1, push 1)
100015 .. 0xf Reserved
10010VAL Push immediate (VAL is signed)90
10011000Push unsigned 1-byte argument 98
10011001Push signed 1-byte argument 99
10011010Push signed 2-byte argument 9a
10011011Return from function (pop 1)9b
10011100Return from function without value 9c
10011101Drop value (pop 1)9d
10011110Call address (pop 1)9e
10011111Jump to address (pop 1)9f
101000Jump (1-byte rel. address)a0
101001Jump (2-byte rel. address)
101002Call (1-byte rel. address)
101003Call (2-byte rel. address)
101004Jump IF (pop 1, 1-byte rel. address)
101005Jump IF (pop 1, 2-byte rel. address)
101006Jump UNLESS (pop 1, 1-byte rel. addr.)
101007Jump UNLESS (pop 1, 2-byte rel. addr.)
101010Compare "<" (pop 2, push 1)a8
101011Compare "<=" (pop 2, push 1)
101012Compare "==" (pop 2, push 1)
101013Compare "!=" (pop 2, push 1)
101014Compare ">=" (pop 2, push 1)
101015Compare ">" (pop 2, push 1)
101016Stack Pointer (push 1)ae
101017Stack Frame Pointer (push 1)af
1011Func-ID Call User Function b0
110M Load 8u (push 1, M is addr mode)c0
111M Store 8u (pop 1, M is addr mode)c8
112M Load 8s (push 1, M is addr mode)d0
113M Store 8s (pop 1, M is addr mode)d8
114M Load 16 (push 1, M is addr mode)e0
115M Store 16 (pop 1, M is addr mode)e8
11K 5Bury dup of top in depth K (max 5)
11K 6Dig up the element in depth K (max 5)
11K 7Reserved
116N Push N+1 zeros to the stack f0
117N Pop N+1 values but keep top f8

Adress Modes (M) for "Load" and "Store" instructions:

   0 ..... address as 1 byte (unsigned) argument
   1 ..... address as 2 byte argument
   2 ..... address as popped value (pop before data)
   3 ..... address as popped + 1 byte (unsigned) argument
   4 ..... address as popped + 2 byte argument
   5-7 ... shuffle instructions (not load/store)

Note: for 16bit load and store operations in mode 3 and 4 the popped data from the stack is multiplied by 2.

A "bury" with K=0 simply duplicates the top element on the stack; A "dig" with K=0 exchages the two top elements on the stack

Execution Model


The function embedvm_exec() executes one single VM instruction and then returns. The user provided callback functions are used to access the vm memory and call user functions.

"

Arduino

" The most popular programming environment for the Atmel AVR is Arduino. The Arduino language is a subset of C++.

Arduino "sketches"/programs appear syntactically very similar to Java. The Wiring language which Arduino derives from has implementations in C++ (Arduino), Java (Processing) and Javascript (processing.js).

Both languages share the same declaration style, loop constructs and arithmetic operators due to their common ancestry in Algol68. Typically, all objects in Arduino are declared globally or on the stack, so like Java, member functions are called with the . operator (eg. LED.flash()).

The language will be very familiar to a Java programmer - but, importantly, Arduino sketches are compiled into native code which runs at full speed with full hardware access. This is critical for getting the most from your microcontroller.

Here is the API.

Arduino provides everything you need to get going: low cost hardware, a free integrated development environment and a bootloader (so you can load code over USB/serial).

"

Core i3

not low-end but just to compare

http://www.hardwaresecrets.com/article/All-Core-i3-Models/951

32K L1 cache

Tegra 4

2013 ARM CPU used in tablets or mb mobile phones

Misc

http://www.cs.arizona.edu/~arvind/papers/lctes03.pdf

T able 1: AX Instructions AX Instruction Description

setpred support for predication in 16-bit code

setsbit sets the ’S’ bit to a v oid e xplicit cmp instructions

setsource sets the source re gister for the ne xt instruction

setdest sets the destination re gister for the ne xt instruction

setthird sets the third operand (support 3-address format)

setimm sets the immediate v alue for the ne xt instruction

setshift sets the shift type and amount for the ne xt instruction

setallhigh indicates ne xt instruction uses all high re gister

---

OK, seems like we want the core of Jasper's VM to fit in 16K or 32K or 64K or 128K. All of these fit in L2 cache on the Core i3s (which is 256k).

If we can get it into 16K, then it'll fit in L1 cache even in some lower-end solutions, and it'll fit in ROM in all but the lowest-end cards.

If we can get it into 32K, then it'll fit in L1 cache in Core i3, and it'll fit in ROM in most of the lowest-end cards.

If we can get it into 64K, it'll fit in ROM in most of the lower-end cards, but it'll take up most or all of the ROM in many of them.

If we can get it into 128K, it'll fit in ROM in some of the lower-end cards, but it'll take up most or all of the ROM in many of them.

(noting that even if the VM interpreter fits in the L1 cache, it would be nice if some of the application code would too, so that we could run small loops entirely in L1)

The embedded Javas and Pythons range from 16K to 64K.

The Apple IIe had 48K of non-bank-switched memory, plus a 16K ROM-like "language card". "Integer BASIC" fit into this 16K "language card" and could run using the other 48K as its RAM. Otoh that 16K/48K is for an 8-bit machine with 16-bit addresses, so for processors with larger instruction sizes and 32-bit or 64-bit addressing, one should scale that up:

so imo one should expect that numbers from the 6502 to at least double on modern processors (16->32 bit addresses, 1 byte -> 2 byte opcodes), so think 32K/96K = 128K total.

.NET Micro needs 256K so that's not crazy.

a "stripped down" eLua needs 128K so i doubt we'll do much better than that.

So let's dream of 16K, initially shoot for 32K, slip to 64K, and not be too unhappy if we end up at 128K. (of course in reality i'm not going to sweat these things too much so it'll probably end up much much larger, but it's interesting to think about). Note that it would be useful to have the most common loops fit into 32k even if the whole runtime or interpreter does not.

otoh if the ISA is more complex, then that's actually better for memory b/c programs can fit in less memory

but the macro (custom instruction) facility should help

hmmm... i guess macros/custom instructions are no different than subroutines (where you push return addr and args onto the stack then JMP), except that they are more compact (higher code density)

i guess that is part of the genius of Forth.

--

http://hackaday.com/2011/02/01/what-development-board-to-use/

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=80840&start=0

"I fear the 16-bit market is a dying breed. 32 bit is now encroaching on the 8-bit market (think LPC ARM) and squeezing out 16-bit."

---

" minibox is about to launch their ARM board the pico-SAM9G45-X which has a Atmel ARM926EJ-S 400MHz MCU for $59-$69. "

http://www.mini-box.com/pico-SAM9G45-X appears to have 32K cache ( http://www.atmel.com/images/atmel_6438_32-bit-arm926ej-s-microcontroller_sam9g45_datasheet.pdf )

---

Cypress PSoC? 4: Up to 48 MHz, MIPS, Flash 16 KB to 32 KB, SRAM 4 KB Cypress PSoC? 5: Up to 67 MHz, 84 MIPS, Flash 32 KB to 256 KB, SRAM 16 KB to 64 KB

---

" To lead off this series, I am looking at processors that cross new low price thresholds because there have been a handful of announcements for such parts in the past few months. Texas Instruments’ 16-bit MSP430 represent the lowest public cost parts which start at $0.25. Moving up the processing scale points our attention to NXP’s 32-bit Cortex-M0 processors which start at $0.65. Rounding out the top end of the batch of new value-priced processors is STMicroelectronics’ 32-bit Cortex-M3 processors which start at $0.85. ... Another area of controversy for processors that push the low-end of the pricing model is how much on-chip resources they provide. To reach these price points, the on-chip resources are quite constrained. For example, the Cortex-M3 part includes 16-kbytes of Flash, while the Cortex-M0 part includes 8-kbytes of Flash. The MSP430 part includes 512-bytes of Flash and 128-bytes of SRAM. These memory sizes are not appropriate for many applications, but there are growing areas of applications, including thermometers, metering, and health monitoring that might be able to take advantage of these resource constrained devices. " -- http://www.embeddedinsights.com/channels/2010/03/26/extreme-processing-thresholds-low-price/

--

in this blog post is a list of popular embedded systems:

    ARM Cortex-M 	
    AVR
    AVR32
    ColdFire
    HC12
    MSP430
    PIC18
    PIC24/dsPIC 	
    PIC32 (MIPS) 	
    PowerPC 	
    RL78 	
    RX100/600 	
    SH 	
    V850 	
    x86 	

---

https://www.spark.io/

    STM32F103 microcontroller
    ARM Cortex M3 architecture
    32-bit 72Mhz processor
    128KB of Flash, 20KB of RAM

i think that has either no instruction cache or an 4K or 8k one, but not at all sure.

the take-home for us is probably the amounts of flash and RAM. again, would be nice to fit the main interpreter in 16k or less, and that the upper limit is about 64k.

---

The E64G401 Epiphany-IV 64-core 28nm Microprocessor has 32KB local (but shared) memory per core (so 32KB x 64 = 2MB total).

http://en.wikipedia.org/wiki/Adapteva

http://www.adapteva.com/wp-content/uploads/2013/06/e64g401_datasheet_4.13.6.14.pdf

---

woah these are cheap:

https://en.wikipedia.org/wiki/Odroid

i think the Exynos 4412 has 32KB/32KB L1 Cache -- http://malideveloper.arm.com/develop-for-mali/development-platforms/hardkernel-odroid-u2-development-platform/

---

http://linuxgizmos.com/intel-unveils-tiny-x86-minnowboard-max-open-sbc/

Raspberry Pi: $25/$35 BeagleBone? Black: $45 MinnowBoard? SBC: $99

" tdicola 13 hours ago

link

This looks neat for people that want a cheap board to hack on embedded Linux. However for serious control of signal generation, acquisition, PWM, servos, etc. you really don't want to be running a multitasking OS. Something like the Beaglebone Black, with its dedicated 200mhz programmable units in addition to embedded Linux, is much more interesting for hackers and makers IMHO.

reply "

" stonemetal 6 hours ago

link

PRU-> programmable real time unit

BBB-> BeagleBone? Black

The BBB has an extra dual core processor that runs at 200Mhz. It is interesting because it is like the processor they teach you about in your intro to computer architecture classes, every instruction is a single cycle instruction. Since it is a co-processor(not running an OS but controllable from the BBB's OS) and execution of instructions is deterministic, it is a good choice for running hard real time code. "

" ah- 13 hours ago

link

I wouldn't call the minnowboard a microcontroller, it's more similar to other single board computers like the Pandaboard and the odroid boards. And 2GB are already common for such boards, so 4GB are really not far off.

reply "

"

outside1234 6 hours ago

link

Does anyone know how the performance on something like this stacks up to something like the Raspberry Pi?

reply

wmf 5 hours ago

link

A 1.4 GHz Silvermont must be many times faster than a 700 MHz ARM11.

reply "

"

kqr2 14 hours ago

link

Intel also has the Galileo board which is hardware and software pin-compatible with shields designed for the Arduino Uno* R3.

http://www.intel.com/content/www/us/en/intelligent-systems/g...

reply

makomk 11 hours ago

link

The Galileo's one of those boards where it's very important to pay attention to the fine print. For example, the GPIO controller is hanging off a relatively slow I2C port, so access to GPIO is much, much slower than even the lowest-end Arduino. Also, it's a modified 486 which takes multiple clock cycles to carry out many instructions that are single-cycle on modern ARM, so it's not as fast at arithmetic as the clock speed would suggest.

reply

tdicola 14 hours ago

link

Be careful though, the Galileo emulates AVR code and is orders of magnitude slower than a real Arduino. Don't expect to pick up any shield and make it work, unfortunately.

reply

jpwright 3 hours ago

link

The Galileo actually only emulates a subset of the Arduino libraries. The AVR libraries themselves are, for the most part, not supported. This makes many popular libraries unusable even when hardware is not an issue.

reply "

" elnate 14 hours ago

link

How does this (note: the MinnowBoard? SBC) compare to a Raspberry Pi?

reply

vonmoltke 9 hours ago

link

Comparing the $99 version to the B ($35):

Overall, probably worth the extra cost if you need the power and features. The question is, who does? I'm considering this for no other reason than I want a board in this form factor and power class that has SATA and PCIe.

reply

nullc 6 hours ago

link

The RPI is really obscenely slow, far slower than the clock rate would suggest even for an arm. The RPI is pretty exciting as a microcontroller, though it's power usage is very high, but as a computer it's a real disappointment.

The real comparison should be with the odroid boards: http://hardkernel.com/main/products/prdt_info.php?g_code=G13... a quad arm (cortex-a9) at 1.7GHz with 2GB ram for ~$60.

reply "

--

" Another note: In high school or my first year of college I told my dad that someday I'd own a 4K Data General NOVA. He said it cost as much as a down payment on an expensive house. I was stunned and told him I'd live in an apartment.

Why 4KB?

Because that was the minimum needed to run a higher level language. To me a computer had to have more than switches an lights. It had to be able to run programs.

" -- http://gizmodo.com/how-steve-wozniak-wrote-basic-for-the-original-apple-fr-1570573636/all

---

about micropython:

chillingeffect 1 hour ago

link

It appears from [0] that the chip of choice is the STM32F045RGT (datasheet [1]). This is from the Cortex M4f series, which includes such wonderful things as a hardware floating-point unit. That is wonderful news, although, this board appears to have no external memory, so it would be limited to 128kB.

[0] https://raw.githubusercontent.com/micropython/pyboard/master... [1] http://www.alldatasheet.com/datasheet-pdf/pdf/510587/STMICRO...

reply

--

" Micro Python has the following features:

More info at:

http://micropython.org/

You can follow the progress and contribute at github:

www.github.com/micropython/micropython www.github.com/micropython/micropython-lib "

--

according to "dec-11-ajpb-d pdp-11 basic programming manual", available from http://bitsavers.trailing-edge.com/pdf/dec/pdp11/basic/DEC-11-AJPB-D_PDP-11_BASIC_Programming_Manual_Dec70.pdf , or as text at https://archive.org/stream/bitsavers_decpdp11baASICProgrammingManualDec70_5936477/DEC-11-AJPB-D_PDP-11_BASIC_Programming_Manual_Dec70_djvu.txt ,

" A. 2 USER STORAGE REQUIREMENTS

BASIC can be run in the minimal 4K PDP-11/20 configuration. With the BASIC program in core, and deducting space reserved for the Bootstrap and Absolute Loaders, approximately 450 words are left for total user storage (program storage plus working storage) . "

i believe this 4k is 4k WORDS, and each word is two bytes, so BASIC takes up most of 8k, with about 900 bytes to spare; that is to say, BASIC takes about 7292 bytes, or just over 7k.

--

according to http://lua-users.org/lists/lua-l/2007-11/msg00248.html , Lua was under 100k on cell phones, and according to http://www.lua.org/about.html , "Under Linux, the Lua interpreter built with all standard Lua libraries takes 182K...", and according to http://www.schulze-mueller.de/download/lua-poster-090207.pdf , Lua fit into 128k ROM.

http://www.luafaq.org/#T1.33 says "Embedding Lua will only add about 150-200K to your project, depending on what extra libraries are chosen. It was designed to be an extension language and it is straightforward to ensure that any user scripts operate in a 'safe' environment (see Sandboxing.) You do not even have to embed the compiler front-end of Lua, and just use the core with pre-compiled scripts. This can get the memory footprint down to about 40K."

and as noted above, there's also the eLua project:

http://www.eluaproject.net/

" It's hard to give a precise answer to this, because this is not only dependable on the footprint of eLua or it's resource requirements but on the final user applications as well. As a general rule, for a 32-bit CPU, we recommend at least 256k of Flash and at least 64k of RAM. However, this isn't a strict requirement. A stripped down, integer-only version of eLua can definitely fit in 128k of Flash and depending on your type of application, 32k of RAM might prove just fine. We have built eLua for targets with less than 10K RAM but you can't do much than blinking an LED with them. It really largely depends on your needs. "

note that instruction sizes affect things somewhat here. if you measure things in words instead of bytes, then we have x86 variable length instruction sizes, compared with (i think?) PDP's 16-bit instruction size, and (i think) APPLE's 6502 8-bit opcodes. And newer machines require more bits per each address. Presumably then the same number of instructions may take up more room in newer machines.

--

contiki:

http://www.wired.com/2014/06/contiki

" While Linux requires one megabyte of RAM, Contiki needs just a few kilobytes to run. Its inventor, Adam Dunkels, has managed to fit an entire operating system, including a graphical user interface, networking software, and a web browser into less than 30 kilobytes of space. That makes it much easier to run on small, low powered chips–exactly the sort of things used for connected devices–but it’s also been ported to many older systems like the Apple IIe and the Commodore 64. "

--

interestingly, at the time Java was introduced, 'Java: an overview' says:

"The size of the basic interpreter and class support is about 30K bytes, adding the basic standard libraries and thread support (essentially a self-contained microkernel) brings it up to about 120K. "

--

http://www.erlang.org/faq/implementations.html

" 8.9 Is Erlang small enough for embedded systems?

..

 Rule of thumb: if the embedded system can run an operating system like linux, then it is possible to get current implementations of Erlang running on it with a reasonable amount of effort.

Getting Erlang to run on, say, an 8 bit CPU with 32kByte of RAM is not feasible.

People successfully run the Ericsson implementation of Erlang on systems with as little as 16MByte of RAM. It is reasonably straightforward to fit Erlang itself into 2MByte of persistant storage (e.g. a flash disk).

 A 2MByte stripped Erlang system can include the beam emulator and almost all of the stdlib, sasl, kernel, inets and runtime_tools libraries, provided the libraries are compiled without debugging information and are compressed: "

--