mdj

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.

Matt

winston19842005@yahoo.com

On Nov 29, 2:54 am, 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.

Umm - you mean for Apple Pascal (and versions before UCSD IV.0) right?

I'm pretty sure IV.0 and up had a real heap. You are probably talking
MARK and RELEASE? IV.0 had new and dispose.

I run IV.0 on a TI-99, which had a lot less space than an Apple (of
any variety). Yes, it does a lot of segment loading when running the
compiler, for example...

mdj

On Nov 29, 6:04 pm, "winston19842...@yahoo.com"
<winston19842...@yahoo.com> wrote:
> On Nov 29, 2:54 am, 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.
>
> Umm - you mean for Apple Pascal (and versions before UCSD IV.0) right?
>
> I'm pretty sure IV.0 and up had a real heap. You are probably talking
> MARK and RELEASE? IV.0 had new and dispose.

Yes, that's what I meant. It was frustrating when writing more
sophisticated applications - on more than one occasion I cobbled
together my own garbage collection regime.

> I run IV.0 on a TI-99, which had a lot less space than an Apple (of
> any variety). Yes, it does a lot of segment loading when running the
> compiler, for example...

I don't have any experience with IV.0, since Apple Pascal stopped at
UCSD II, unfortunately.

Matt

Paul Schlyter

In article <e32c8459-af7c-49e0-81d7-f267535113fa@i29g2000prf.googlegroups.com>,
winston19842005@yahoo.com <winston19842005@yahoo.com> wrote:
>
>Umm - you mean for Apple Pascal (and versions before UCSD IV.0) right?
>
>I'm pretty sure IV.0 and up had a real heap. You are probably talking
>MARK and RELEASE? IV.0 had new and dispose.

Earlier versions of UCSD actually had NEW as well, so the family of
dynamic memory allocation functions were NEW, MARK and RELEASE.

Early versions of C took a similar approach - instead of malloc() and
free() it used brk() and sbrk(). The approach was the same: a
"stack-based heap" where you could free only the most recently
allocated memory blocks.

Turbo Pascal 1.0 had only new/mark/release, but version 2.0 added
a dispose function.

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

Paul Schlyter

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/

Paul Schlyter

In article <e32c8459-af7c-49e0-81d7-f267535113fa@i29g2000prf.googlegroups.com>,
winston19842005@yahoo.com <winston19842005@yahoo.com> wrote:
>
>Umm - you mean for Apple Pascal (and versions before UCSD IV.0) right?
>
>I'm pretty sure IV.0 and up had a real heap. You are probably talking
>MARK and RELEASE? IV.0 had new and dispose.

Earlier versions of UCSD actually had NEW as well, so the family of
dynamic memory allocation functions were NEW, MARK and RELEASE.

Early versions of C took a similar approach - instead of malloc() and
free() it used brk() and sbrk(). The approach was the same: a
"stack-based heap" where you could free only the most recently
allocated memory blocks.

Turbo Pascal 1.0 had only new/mark/release, but version 2.0 added
a dispose function.

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

David Schmenk

Paul Schlyter wrote:

[snip]

>> 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
>
>

I think an extremely simplistic memory manager would make the
environment a little too restrictive. I currently have a reference
counted handle based manager with compaction and optional swapping to
file (not quite figured out). A trade-off from a simple malloc/free
implementation and a full mark and sweep garbage collector. I hope it
works well because implementing another memory manager in assembly would
suck. I wanted a way to swap memory to a file to give the environment
the ability to run a decently sized (relatively speaking) app. The
issue with a handle based approach is that the handle table itself takes
up a some space. Finding the right size for the table will take some time.

Dave...

Paul Schlyter

In article <e32c8459-af7c-49e0-81d7-f267535113fa@i29g2000prf.googlegroups.com>,
winston19842005@yahoo.com <winston19842005@yahoo.com> wrote:
>
>Umm - you mean for Apple Pascal (and versions before UCSD IV.0) right?
>
>I'm pretty sure IV.0 and up had a real heap. You are probably talking
>MARK and RELEASE? IV.0 had new and dispose.

Earlier versions of UCSD actually had NEW as well, so the family of
dynamic memory allocation functions were NEW, MARK and RELEASE.

Early versions of C took a similar approach - instead of malloc() and
free() it used brk() and sbrk(). The approach was the same: a
"stack-based heap" where you could free only the most recently
allocated memory blocks.

Turbo Pascal 1.0 had only new/mark/release, but version 2.0 added
a dispose function.

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

Paul Schlyter

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/

Eric

On Nov 27, 12:38 am, David Schmenk <dschm...@YUCH.gmail.com> wrote:
> As soon as I finish working out some issues with the garbage
> collector (I don't like automatic garbage collectors) I should have
> something to try out.

I assume you've studied NanoVM. That takes a lot of liberties that
work great on a small machine but wouldn't (or couldn't) work well on
a larger machine. The way he uses the high bit of an integer or object
reference to indicate whether it needs to be collected is both
ingenoius and perhaps dangerous. You then have only 15 bit integers
instead of 16 bit integers and that can lead to buggy code.

To me the huge elephant in the room is not the VM or the garbage
collector, but rather the class libraries. Java developers are used to
a lot of baked-in classes and methods and it's going to frustrate them
if you only have a small subset, such as that offered by NanoVM.

I don't think a discussion of performance of this Java dialect against
Apple Pascal is particularly relevant. I don't see these as
competitors. There are very few Apple Pascal developers left, based on
my unscientific observation from the newsgroups. And the number of
people who really want to play with Java on the Apple II may also be
small. Many Apple II fans grew up before the days of OOP coding and
they probably wouldn't see much reason to use Java.

But I don't want to be pessimistic because I share your enthusiasm in
the final project. It would be sweet, and almost a sin against nature
to take a super modern language and back-port it to work on a machine
that wasn't even sold any more before the first discussions of Java
ever showed up in its earliest form. There's also a little bit of
"take that, Mac" payback involved here :-)

Eric