From: | Jean-Pierre |
Date: | 7 Aug 2000 at 07:55:11 |
Subject: | AMIOPEN: Comparing Amiga2k (Tao's Elate) with Microsoft's .net |
http://jonathanclark.com/diary/amiga/
Comparing Amiga2k (Tao's Elate) with Microsoft's .net
I played around with the Amiga SDK for a little bit and have 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 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 Canada. 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.
The core of the Elate system revolves around a gcc backend replacement that
spits out assembly to a virtual instruction set they invented called VP (I
assume for virtual processor). They then run this through their assembler
to create a binary. Then they have their own "loader" program, a native
app, that translates VP to native code. I think it's a mislabeling to call
this Dynamic Translation. It's more like JIT or static translation.
Dynamic translation occurs dynamically over the course of the program's
runtime because initial information is incomplete or performance can be
enhanced by studying execution patterns. A good example would be Alpha's
FX32! software that convert Intel into Alpha instructions over the course of
the program. Dynamic translation usually requires a translator and an
emulator because static translation is not possible. To be fair, Elate does
split up it's translation work into modules, but this is purely to reduce
the speed hit of having to do everything at once.
If you have been following Microsoft's latest news, you might also be aware
that the ".net" platform 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.
- VP has less type information in it's assembly 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.
- 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.
- Noticeably absent in Microsoft's .net rollout is any support for
Java. Since Elate uses gcc, they were able to fairly easily port Sun's JVM
and JDK to their VP. They also wrote their own JIT compiler to convert java
instructions to VP - and 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 swing program in 2MB without having
to install a 10MB+ JVM.
- Elate has a poor debugger compared to MS's offering which is a
very important component of development work. Also gcc is still very
lacking in the incremental compiling and linking territory - making working
with large C++ projects painful. I'm sorry to say, I don't think this last
gripe will change much.
- 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 simply becomes a fancy JIT compiler on desktop systems. (They
claim to have one of the fastest in the industry). However, the Elate system
is a viable replacement for WindowsCE for embedded systems and it has a lot
less baggage. I will not use .net for anything serious until it's portable
to more systems than "Windows", and I don't see MS inventing an API that
would supplants Win32. At the same time, I'm not likely to use a system that
requires royalties, which Elate currently does. Finally, I have my doubts
as it if Amiga can create their own API that will compete with Win32 or JDK.
Sun had a lot of talented people work on the JDK over the course of several
years and it's still not as complete MS's offerings.
Links
The Tao Group
Amiga 2000
Microsoft's .NET information
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html