In article <889fa671-354d-433e-a2fe-c0c9f3d79b1b@s19g2000prg.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:
>On Nov 29, 5:16 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:
>> mdj wrote:
>>
>> [snip]
>>
>> >> We've learned a few things since then, but we've forgotten so much.. ;-)
>>
>> > Oh, I doubt it's possible to get more than a few percent improvement
>> > out of the interpreters execution speed. Certainly big chunks of the
>> > OS itself could do with an overhaul, but one of the advantages of
>> > going for the JVM approach would be building it from scratch to run
>> > under ProDOS (and possibly be able to relocate itself into the
>> > Auxiliary Language Card *hint hint*)
>>
>> There will probably be a 64K version and a 128k version, just like Apple
>> Pascal 1.3. For the 128K version, I'm planning on putting the bytecode
>> interpreter in the AUX language card and data in AUX mem. 6502 and
>> bytecode would go in main mem. This is somewhat backward from Apple
>> Pascal 1.3 where p-code went into AUX mem. I'm planning on doing a lot
>> more code swapping, so using main mem for methods seems like a good
>> idea. But I'm not fixed on the idea, as I'm going to implement the 64K
>> version first.
>
>Great minds... :-)
>
>> > I think the really interesting improvements would come from a runtime
>> > profiler/compiler that applied all the the feasible dynamic
>> > optimisations.
>>
>> > Matt
>>
>> I think it would be really interesting just to see it work ;-) For
>> Java, the bytecode interpreter is just a piece of the pie. The memory
>> manager/garbage collector probably has as much impact on performance.
>> Just a functional JVM is going to be a tight sqeeze, much less any
>> runtime hotspot optimizations. Although a method profiler might be
>> pretty easy and not take much space. A real class compiler for
>> bytecode->6502 shouldn't be too hard. There will be a fairly easy way
>> for native methods to interface to the runtime. At the moment I think
>> it will have to be position independent code, which is an interesting
>> exercise on a 6502.
>
>Yeah. I'm interested to see how you manage the heap - with so little
>space it could potentially thrash really badly. The p-system got
>around this problem by 'disposing' the dispose procedure and simply
>having a stack instead, but for Java that's not an option.
One option in Java is to *never* release allocated memory blocks.
Most versions of javacard takes this approach. So if you write
software in Java for the javacard environment, you'll have to
think very carefully before allocating anything, or else you may
soon run out of memory!
(javacard is an interpreter for a subset of Java intended to run
on smartcards, i.e. small chips embedded into credit card size
cards. The chip doesn't have any power source of its own but gets
powered only when inserted in a card reader. The java classes in
this environment will have a lifetime equal to the lifetime of the
card)
>Matt
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW:
http://stjarnhimlen.se/