----- Forwarded message from eleftherios stavridis <es@xxxxxxxxxxxxxxxxxx> -----
Envelope-to: scgmille@localhost
Delivery-date: Sun, 04 Jan 2004 13:57:01 -0600
From: eleftherios stavridis <es@xxxxxxxxxxxxxxxxxx>
To: scgmille@xxxxxxxxxxxxxxxxxx
Subject: Re: ref: SISC for J2ME
On Sun, 4 Jan 2004 scgmille@xxxxxxxxxxxxxxxxxx wrote:
> The idea is an interesting one, but from my knowledge of the MIDP and
> CLDC specifications, the biggest problem is available memory.
> SISC lite itself occupies nearly 200k compressed in storage. There are
> places where memory usage could be trimmed, but it would be very
> difficult indeed to squeeze into the 32k + 8k profiles of those
> specifications.
Realistically speaking, modern devices have much larger memory resources.
MIDP 2.0 specifies:
- 256 kilobytes of non-volatile memory for the MIDP implementation, beyond
whats required for CLDC.
- 8 kilobytes of non-volatile memory for application-created persistent
data.
- 128 kilobytes of volatile memory for the Java runtime (e.g., the Java
heap)
Compare that to,
Nokia 3600 (CLDC 1.0/MIDP 1.0):
Heap Size: Free RAM, 1.4 MB
Shared Memory for Storage: Free user memory, 3.4 MB + MMC
Max Jar File Size: 4MB (with WAP GW restrictions)
Nokia 6600 (CLDC 1.0./MIDP 2.0):
Heap Size: 3MB
Shared Memory for Storage: 6 MB + MMC (it comes with a 32MB storage card
in the box)
Max Jar File Size: (unlimited)
Nokia 6230 (probably the first CLDC 1.1/MIDP 2.0 device to hit the
market, it's targeted at the low-end of the market):
Heap Size: 512 KB
Shared Memory for Storage: 3.5 MB + MMC
Max Jar File Size: 128kb
Obviously, memory capabilities depend on the price of a device but in
general terms heap sizes of 512Kb can safely be assumed. The Nokia 6600 is
a big hit in Europe and it is likely to set the trend for all new devices.
It is important to look ahead and not to target old devices imo as they
are getting replaced quickly.
> A better approach would be to use Kawa or Bigloo, both Scheme ->
> bytecode compilers. That way you would avoid the interpreter memory
> overhead. Unfortunately you would not be able to do on device
> development with that mechanism.
A compiler that produces .class files is essential for the distribution of
applications and this is part of my proposal for a J2ME version of SICP.
An interpreter is much more desirable but it requires that it's either
embedded in applications or users must have it installed on their phones.
Having both is best.
> If you don't mind, I'd like to forward your request and this response to
> the SISC development mailing list, to get some other input. I'll keep
> thinking about it as well.
>
> Scott
>
Please do.
Cordially,
es
----- End forwarded message -----
--
pgpRz8SQYrW7h.pgp
Description: PGP signature
|
