Comparing Amiga2k (Tao's Elate) with Microsoft's .net

I played around with the Amiga SDK for a little bit and have had some discussions with The Tao Group.   Amiga licensed the OS called Elate from the Tao Group and is remarketing it under the Amiga label.  Amiga, the company, that exist today is not the same Amiga from years past. A different group of people bought the name - I think it was $13 mil for all of Amiga’s resources.   The Tao Group is based in Reading England, while Amiga is in WA USA.   They collaborate loosely, but it looks like the Tao Group is primary focused on embedded platforms and uses the JDK for their API, while Amiga wants to conquer the desktop world with their own API (which has yet to be developed).  At this point Amiga offers little new over what the Tao Group has other than repacking, a nice box, and a manual (which has many errors).  Searching either companies website, and you will only find vague information with lots of marketing speak.  Here is the run down from a technical perspective.

Most of the programs created for Amiga2k use a modified version of gcc (Gnu C Compiler) that spits out assembly to a virtual instruction set they invented called VP (Virtual Processor?).  They then run this through a VP assembler to create a VP binary.   The AmigaSDK uses a loader program called elate/elate.exe to translates VP to native code when it is run.  A user may can write VP assembly directly and not use gcc (in fact the kernel is written entirely in VP assembly) or use another compiler - but I currently do not know of any other compilers that are available at this time. The Javac compiler is not available as an Elate app because of licensing problems with sun - but you can still write java apps on your hosted system and copy them over. The Amiga SDK manual states that the javac compiler is available and tells you how to use it... but trust me it's not there.

If you have been following Microsoft’s latest news, you might also be aware that the “.net” compiler technology is pretty similar in design.  MS’s compilers (C++, Visual Basic, and others) will now spit out a virtual processor instruction set that gets converted to native code at install or run-time.  The main difference between the two are :

-         VP pretends like the virtual machine is always little endian (what is endianess?) even when it is not. This means on big endian systems (as most non-Intel platforms are) a byte swap operation must be preformed every time memory is loaded to or stored from an integer register from main memory. Most processors have a fast byte swap operation, but this still increases the size of your executable and slows it down unnecessarily. The advantage is that the developer no longer has to think of endian issues and no portability problems will arise. .NET on the other hand, always uses the native byte format for loads and stores. This means you don't have the byte swap overhead but the developer may need to be aware of endian issues in some cases. Because .NET has a built in type system it can automatically serialize your objects (what is serialization?) which allows you to forget about endian issues.

Slight correction: A developer at Tao has informed me that the Elate compiler/translator does not actually perform a byte swap on each integer register load/save. Instead, they perform address translation on every byte or short pointer. This can be done on all systems by XORing a mask with the pointer before it is used. The translator is also smart enough to notice some XORs cancel each other out and some address translations can be optimized away. The Tao developer also stated that the XOR operations often come for free on pipelined cpus. This approach would be a lot faster when dealing with integer operations because ints are always loaded and stored directly to memory with no additional overhead, however programs that do a lot of string operations (like web servers) may see some slow down because these usually operate with 8bit or 16bit character values. Also one weird artifact of this memory mangling is that if you use DMA or memory mapped ports you will have to pretend like everything is backwards from how it actually is.

-         VP has less type information in it's binaries than .net. That is VP instructions operate on explicit conventional types - like ints, floats, and pointers. .net extends this and includes it's own type system that can create new object types and operate on them. This allows .net to perform "generic" processing in a type independent manner - much like templates in C++. Also, because it always knows all the types in an object, reflection is possible and serialization of objects can be easily performed. (reflection is the ability to examine your type information at runtime). This also allows for easier sharing of objects between two different programs. To clarify this more here is an excerpt from an interview with Anders Hejlsbeg, the lead programmer of MS's c-sharp:

"If the instructions in the IL embed type information -- if, for example, an Add instruction is not an Add, but is an Add int or an Add float or an Add double -- then you've baked the type into the instruction stream and the IL is not generic at that point. Our IL format is actually truly type neutral. And, by keeping it type neutral, we can add generics later and not get ourselves into trouble, at least not as much trouble. That's one of the reasons our IL looks different from Java byte code. We have type neutral IL. The Add instruction adds whatever the two things are on top of the stack. In a generic world, that could translate into different code when the generic is instantiated. "

-         Both systems offer static code compilation/translation to native code. From the sound of things the .NET platform has a much slower translation process and they recommend it only be done at install time. I would expect that they are doing more of the "compilation" work at this point, while Elate, which has a much faster translation time, does most of compilation work (register allocation, inlining etc) ahead of time either by a human assembler or a compiler such as gcc. Elate also has what they refer to as "Dynamic translation," which is similar to JIT compilation of Java classes. Modules can be translated as they are used so modules that go largely unused will not slow down the loading processes. But, Elate executable will, in general, not load faster than a native counterpart regardless of their statements Elate binaries are smaller. This is because operating systems don't load an executable into memory all at once. They load the first few pages and memory map the rest from disk so it is paged it in as needed. The term dynamic translation is a little confusing because this term was coined by emulator authors and used to mean emulation+translation. Elate and .NET never run code under emulation.

-         The Amiga SDK (which cost $100) initially came with a license agreement that required a $3 royalty on every copy of software developed with the system. They have since announced they have changed this policy but I have not seen the new license agreement. No word yet on how much .net will cost (probably around $100-$200). Although .net will not require royalties, it will only run on a MS OSes (CE, 95/98/NT/2k) This requirement will likely change in the future once .net gets standardized and new vendors make versions for UNIX. .net binaries are not explicitly tied to MS's OS so this is possible, however many of the features in .net are tied to the runtime library which does require Win32. I think it will be a good 2 years before we see a solid UNIX implementation. Someone told me that to "get branded" for .net, the cost would be $10,000.

-         Noticeably absent in Microsoft's .net rollout is any support for Java. The Tao Group offers their own VP optimized JVM and they written their own implementation of the JDK (no small feat!). Their JIT compiler, which is reported to be the fastest in the industry, can convert java instructions to VP - and then they can use their existing translator to convert to native instruction. This means, not only can you compile java programs to binary VP or native instructions you have the JDK available on all the platforms they have ported to. What is really nice here is that you can compile a Java program that uses any subset of the Personal Java sdk into a single distributable executable. I.e. a run swing-based program in 2MB without having to install a 10MB+ JVM. The Tao Group was also the first vendor to have a Sun certified JVM demonstrating their commitment to being standard complaint.

-         Elate has a poor debugger compared to MS's offering which is a very important component of development work. Another small issue is that gcc is completely lacking in the incremental compiling and linking territory. It also places debug information in the executable. For developers of large applications the executable can grow to 100MB or more (because of debug info) and linking can take minutes to complete. Use of templates and include files compounds this problem. My main reason for switching to MS VC++ instead of Linux as my development environment was for this reason.

-         Elate can function as an OS of it’s own with interrupt handling and file system capabilities, while .net requires a hosting OS such as WindowsCE.  This is only important for embedded systems – on the desktop models both systems are hosted.

-         Elate exists today, while .net is only available to a few thousand people in alpha form.  .net will roll out in early 2001.

  Reading this you might think that I am biased towards .net, but I actually like the Tao Group enough to consider working there. The main advantages it has to offer are Java and a hosting OS. Since Java is already portable, the Elate system becomes a fancy JIT compiler on desktop systems. Being able to distribute a Java app to customers as a single 2MB download is a big advantage over existing methods which require a 10+MB additional overhead assuming you cannot count on the user to have your JVM already installed. Also since the .NET platform will not be available for Linux, Mac, Sun, SGI, etc. it's binary portability doesn't offer much to desktop developers. For embedded systems, Elate offers a smaller footprint than WindowsCE. Developers wanting to develop Java apps for WindowsCE are pretty much out of luck unless it's a monster of a microprocessor.

Initially I was hesitant to use the Amiga SDK for anything because of their royalty requirement, but now that this restriction has been removed I look forward to using it to develop some cross platform applications. Currently Amiga only offers a linux version, even though the Tao Group has ported the "OS" to many other platforms. Amiga president Bill McEwen says the Win32 version is "scheduled to be out by the end of the month, but no plans for a Mac version."

Links

The Tao Group
Amiga 2000
Microsoft's .NET information