On Fri, Sep 14, 2001 at 02:26:37PM -0700, Hong Zhang wrote:
> > We can't do that. There are platforms on both ends that
> > have _no_ native 32-bit data formats (Crays, some 16-bit
> > CPUs?). They still need to be able to load and generate
> > bytecode without ridiculuous CPU penalties (your Palm III
> > is not running on a 700MHz Pentium III, after all!)
>
> If the platform can not deal with 32-bit value, the runtime
> can convert it to their own in memory format. Almost all
> platforms can deal with 32-bit value from file/data base.
And good riddance for the platforms that can't (or for
which it is painful/painfully slow)? I'm sorry but I
must have chosen the wrong door, I thought I came to
the *portable* bytecode discussion :-)
> All these is based on the assumption of portable bytecode
> file. If the file is just snapshot of runtime image, there
> is not need to discuss much here, since each runtime can
> just choose its own format without worry about interexchange.
The bytecode is not just a snapshot for that particular
platform. It should also be useable on other platforms,
with maybe some load-time fixups. That platform can then
choose to dump the bytecode in its own most natural format.
But all these formats should be easily understandable across
all the platforms.
> Hong
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
