KVM Porting Guide
Java Kilo Machine Midp 2.0
NHAL Reference
  KVM is designed to run on compact hardware environment. That means we must consider the limited hardware resource like CPU ability, storage size, input and output peripherals. Fortunately, KVM just need consume few memory footprints, few storage size and CPU time. The basic environment to run KVM is the machine owns one or two megabytes memory and storage size. For my experience, MIDP 2.0 and CLDC 1.0.4 must consume 500K to 1000K storage size and 100 to 500 heap size. But it・s a big challenge for current embedded system to run such a huge application. We may image that most of your hardware spend most of resource to run KVM, is that valuable to put a KVM on our device and the only advantage is to run a small java midlet. That's a business issue
Porting layer functions and target device (required hardware support)
  RI is reference implementation released from SUN Micro-system. Of course, it is most common reference for all of us. But RI is not real business solution for us. Because most of it does・t design for a real hardware environment, it just designs for workable. It consumes lots of resource to do graphic implementation and waste so many memory footprints to do instance creation. RI do been a reference model but it・s still important for KVM porting.

The basic hardware requirements of KVM are a small storage to store java runtime classes, small memory heap for runtime requirement, a simple keypad to produce a key inputting and a generic graphics system to show GUI. Most of these assumptions are right but not all of compact devices have a generic graphics system. Some devices just provide a vide buffer for read and write image data and don・t have a graphics system like your PC. For these machines, you need implement a basic primitive drawing and imaging functions. I suggest implementing a small generic graphics system and replacing the graphic code of RI. Of course, I will mention this issue at next topic. The biggest challenge is that RI assumes all of target device owning a whole standard C runtime library. I must say this assumption is not right. Most of devices don・t implement such a huge C library but a compact version of CRT. Here is a list of porting requirement.

  • Memory Management
  • Storage System (RMS)
  • File System (For Classes Loading)
  • Graphics System
  • Input Device (Keypad or Touch pad)
Using a compact hardware adapter
  For such variable compact systems, shall we just fellow the architecture of RI? Why don・t we implement a abstract hardware wrap to replace the variable outside environment. For example, all we requirements of graphics system is just holding a image buffer and drawing it. Why don・t we implement our platform independence graphics library and use the library to replace the implementation of RI? My idea to port the Kilo VM is to design a simulator hardware environment and make our VM core runs on it.

I have implemented a compact hardware wrap and name it "NHAL". Here HAL is abbreviation of "Hardware Adapter Layer" and N is "Native". The wrap now supports keypad and graphics system. That means if I can make sure the wrap run properly on device target then we may base on this wrap to test and implement our graphics system of KVM and keypad input.