Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4358 > unrolled thread

PLASMA 2.0

Back to article view | Back to comp.sys.apple2.programmer

Contents

  PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-16 11:43 -0700
    Re: PLASMA 2.0 Steve Nickolas <usotsuki@buric.co> - 2018-03-16 20:47 -0400
      Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-17 07:06 -0700
    Re: PLASMA 2.0 John Brooks <jbrooks@blueshiftinc.com> - 2018-03-16 18:00 -0700
      Re: PLASMA 2.0 Antoine Vignau <antoine.vignau@laposte.net> - 2018-03-16 22:18 -0700
        Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-17 07:36 -0700
      Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-17 07:34 -0700
        Re: PLASMA 2.0 Michael J. Mahon <mjmahon@aol.com> - 2018-03-17 10:05 -0500
          Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-17 20:56 -0700
            Re: PLASMA 2.0 Michael J. Mahon <mjmahon@aol.com> - 2018-03-18 00:59 -0500
              Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-18 07:47 -0700
                Re: PLASMA 2.0 Michael J. Mahon <mjmahon@aol.com> - 2018-03-21 00:23 -0500
        Re: PLASMA 2.0 John Brooks <jbrooks@blueshiftinc.com> - 2018-03-18 01:10 -0700
          Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-18 08:06 -0700
            Re: PLASMA 2.0 John Brooks <jbrooks@blueshiftinc.com> - 2018-03-18 12:20 -0700
              Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-18 13:56 -0700
                Re: PLASMA 2.0 John Brooks <jbrooks@blueshiftinc.com> - 2018-03-18 17:35 -0700
    Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-23 13:32 -0700
      Re: PLASMA 2.0 Antoine Vignau <antoine.vignau@laposte.net> - 2018-03-23 14:07 -0700
        Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-23 17:22 -0700
    Re: PLASMA 2.0 Michael Mann <gmail@ware4.com> - 2018-03-23 16:44 -0700
      Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-23 17:20 -0700
        Re: PLASMA 2.0 mmphosis <mmphosis@macgui.com> - 2018-03-24 01:13 +0000
          Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-23 19:09 -0700
        Re: PLASMA 2.0 Steve Nickolas <usotsuki@buric.co> - 2018-03-23 21:55 -0400
          Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-23 19:12 -0700
            Re: PLASMA 2.0 Antoine Vignau <antoine.vignau@laposte.net> - 2018-03-24 00:34 -0700
              Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-24 07:51 -0700
    Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-28 15:39 -0700
      Re: PLASMA 2.0 Michael J. Mahon <mjmahon@aol.com> - 2018-03-28 20:52 -0500
        Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-29 07:17 -0700
          Re: PLASMA 2.0 Zellyn <zellyn@gmail.com> - 2018-03-29 08:12 -0700
            Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-29 22:19 -0700
    Re: PLASMA 2.0 Tom Porter <laseractiveguy@gmail.com> - 2018-03-28 23:02 -0700
      Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-29 07:21 -0700
    Re: PLASMA 2.0 "Frank M." <frank_o_rama@hotmail.com> - 2018-03-29 08:25 -0700
      Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-29 22:21 -0700
      Re: PLASMA 2.0 "Frank M." <frank_o_rama@hotmail.com> - 2018-04-01 07:48 -0700
        Re: PLASMA 2.0 "Michael J. Mahon" <mjmahon@aol.com> - 2018-04-01 13:12 -0700
          Re: PLASMA 2.0 Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2018-04-02 00:02 -0500
            Re: PLASMA 2.0 Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2018-04-03 00:07 -0500
              Re: PLASMA 2.0 MG <guidero@gmail.com> - 2018-04-02 22:35 -0700
              Re: PLASMA 2.0 Michael J. Mahon <mjmahon@aol.com> - 2018-04-03 13:47 -0500
                Re: PLASMA 2.0 Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2018-04-04 04:38 -0500
    Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-30 15:46 -0700
      Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-03-31 13:25 -0700
    Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-04-12 18:43 -0700
    Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-04-14 08:43 -0700
      Re: PLASMA 2.0 Michael J. Mahon <mjmahon@aol.com> - 2018-04-14 21:26 -0500
        Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-04-15 07:35 -0700
          Re: PLASMA 2.0 "Michael J. Mahon" <mjmahon@aol.com> - 2018-04-15 16:24 -0700
            Re: PLASMA 2.0 Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-04-23 23:01 -0700
      Re: PLASMA 2.0 John Brooks <jbrooks@blueshiftinc.com> - 2018-04-15 00:24 -0700
        Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-04-15 08:10 -0700
          Re: PLASMA 2.0 John Brooks <jbrooks@blueshiftinc.com> - 2018-04-15 10:22 -0700
            Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-04-15 13:00 -0700
              Re: PLASMA 2.0 John Brooks <jbrooks@blueshiftinc.com> - 2018-04-15 15:17 -0700
    PLASMA 2.0 Michael Pohoreski <michael.pohoreski@gmail.com> - 2018-04-24 08:54 -0700
      Re: PLASMA 2.0 David Schmenk <dschmenk@gmail.com> - 2018-04-25 06:37 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4429

> 
> So, here is a list, in no particular order, of the version 2 improvements to date:
>

Hi. I'm very interested in this new language. My background is 25 years of being a software programmer. I've clicked on the github links a couple times, and I end up in a mess of files and get requests and such. (I was using Subversion when I retired, so I haven't played with Git, although I understand that it's all the rage, these days).

My point is that I'd like to see this new language, but a trip to github sure ain't doin' it for me. Is there an example program that shows off EVERY feature? Its purpose is irrelevant; I just want to see the language from 5000 feet: what do variables and functions and closures look like? How are they defined and called? What scopes are available for the above? How about inline assembly? What common-day language features does Plasma provide? Etc.

Can the author please post a show-it-all-off program, here? A couple hundred lines of code that use every feature will give me a picture that's worth 1000 words. I'd like to very possibly use it to program something for the Apple II, but I just don't have enough time to learn git and wade through git pulls. If I can see the example program, I'll know immediately if it'll suit my needs. And from what I'm reading--just the comments, here--I'm thinking that it may be a good fit.

Thank you in advance for indulging me, if it's possible. I would also remind the author that a show-it-all-off program is fantastic marketing to many people, so if it doesn't yet exist, and must be coded, I would heartily encourage him to take the time to do so.

:-)

[toc] | [prev] | [next] | [standalone]

#4430

On Friday, 23 March 2018 16:44:55 UTC-7, Michael Mann  wrote:
> > 
> > So, here is a list, in no particular order, of the version 2 improvements to date:
> >
> 
> Hi. I'm very interested in this new language. My background is 25 years of being a software programmer. I've clicked on the github links a couple times, and I end up in a mess of files and get requests and such. (I was using Subversion when I retired, so I haven't played with Git, although I understand that it's all the rage, these days).
> 
> My point is that I'd like to see this new language, but a trip to github sure ain't doin' it for me. Is there an example program that shows off EVERY feature? Its purpose is irrelevant; I just want to see the language from 5000 feet: what do variables and functions and closures look like? How are they defined and called? What scopes are available for the above? How about inline assembly? What common-day language features does Plasma provide? Etc.
> 
> Can the author please post a show-it-all-off program, here? A couple hundred lines of code that use every feature will give me a picture that's worth 1000 words. I'd like to very possibly use it to program something for the Apple II, but I just don't have enough time to learn git and wade through git pulls. If I can see the example program, I'll know immediately if it'll suit my needs. And from what I'm reading--just the comments, here--I'm thinking that it may be a good fit.
> 
> Thank you in advance for indulging me, if it's possible. I would also remind the author that a show-it-all-off program is fantastic marketing to many people, so if it doesn't yet exist, and must be coded, I would heartily encourage him to take the time to do so.
> 
> :-)

Read this page:

https://github.com/dschmenk/PLASMA/blob/master/README.md

Follow the link at the top to the Release notes (with disk images to click on and download). Then, watch some videos:

https://www.youtube.com/watch?v=_JEqbczrvsk&list=PLlPKgUMQbJ79VJvZRfv1CJQf4SP2Gw3yU

That should get you started, at least.

Dave...

[toc] | [prev] | [next] | [standalone]

#4432

I looked at version 1, read through various web pages of documentation,
downloaded the disks, tried the demos, looked at the code, wrote a bit of
code, compiled my own code on the Apple II (in an emulator.)

PLASMA is amazing!  I appreciate you creating all of this.

[toc] | [prev] | [next] | [standalone]

#4434

On Friday, 23 March 2018 18:13:28 UTC-7, mmphosis  wrote:
> I looked at version 1, read through various web pages of documentation,
> downloaded the disks, tried the demos, looked at the code, wrote a bit of
> code, compiled my own code on the Apple II (in an emulator.)
> 
> PLASMA is amazing!  I appreciate you creating all of this.

I'm glad you like it! Version 2 is shaping up to be quite an upgrade. The actual language, however, won't change much. Any investment in Ver 1 will move easily to version 2.

I should mention that with the JIT parameters tuned for the SIEVE benchmark, it completes in just about 4 seconds. 4X faster than the interpreted code. Automagically.

Dave...

[toc] | [prev] | [next] | [standalone]

#4433

On Fri, 23 Mar 2018, David Schmenk wrote:

> https://www.youtube.com/watch?v=_JEqbczrvsk&list=PLlPKgUMQbJ79VJvZRfv1CJQf4SP2Gw3yU

I almost get the idea that it might be possible, and not even particularly 
difficult, to implement C89 on top of the Plasma machine.

-uso.

[toc] | [prev] | [next] | [standalone]

#4435

On Friday, 23 March 2018 18:55:16 UTC-7, Steve Nickolas  wrote:
> On Fri, 23 Mar 2018, David Schmenk wrote:
> 
> > https://www.youtube.com/watch?v=_JEqbczrvsk&list=PLlPKgUMQbJ79VJvZRfv1CJQf4SP2Gw3yU
> 
> I almost get the idea that it might be possible, and not even particularly 
> difficult, to implement C89 on top of the Plasma machine.
> 
> -uso.

Probably not too difficult. The PLASMA compiler is about half the complexity of a small C compiler, kind of like C--. But it runs pretty well self hosted on a stock Apple II. Not sure C89 would.

Dave...

[toc] | [prev] | [next] | [standalone]

#4438

In case you did not know, the utility disk of the SPVHD device by Cédric Peltier is written in Plasma ;-)
av

[toc] | [prev] | [next] | [standalone]

#4442

On Saturday, 24 March 2018 00:34:05 UTC-7, Antoine Vignau  wrote:
> In case you did not know, the utility disk of the SPVHD device by Cédric Peltier is written in Plasma ;-)
> av

Yes, he was a very brave early adopter. He must have had to fight through some primitive libraries and bugs but never once asked for support. Not sure if that means PLASMA is that easy to learn, or Cedric is very diligent. Maybe both :-)

Dave...

[toc] | [prev] | [next] | [standalone]

#4468

After killing the last bug with the JIT, time to test out what it can really do.

As a quick review, the JIT compiler will recompile the PLASMA bytecode into ~optimized 6502 machine code. The JIT compiler source is cleaned up quite a bit. Worth checking out: https://github.com/dschmenk/PLASMA/blob/devel/src/libsrc/apple/jit.pla

There are three tunable parameters used by the VM to determine when to let the compiler take a swing at the bytecoded routine: Initialization warmup, runtime function call count, and function size. Another parameter isn't tuneable; the VM has to be built with the size of the destination codebuffer fixed-in. I wrote a little utility to adjust the tunable parameters from the command line so the effects can be easily measured without having to rebuild anything.

For my testing, I chose the PLASMA compiler, PLASM, and measured the time it took to compile the SIEVE.PLA benchmark. It is a pretty small program, but I measured the time from pressing enter to when the prompt returned. There is a lot of time taken to just load the module and dynamically link it which is the same regardless. Nevertheless, it was easier to measure the total time. I first did a baseline measurement with the standard bytecode interpreted PLASMA VM, then ran through a series of values to fid the best performance.

Test: +PLASM SIEVE.PLA

Baseline PLASMA VM: 18.8 seconds (average of 3 runs)

For the JIT compiler, the values iterated through were:
Warmup count: 0, 32, 64, 128, 1024
Then call count: 1, 8, 16, 32, 64, 96
Then max size: 256, 128, 64

Since formatting the tabulated data will probably be a disaster, let me summerize the results. By far, the most important parameter is the call count. The warmup count only had small effect, and it was detrimental (it just slowed things down). Here are the best times for the combination of warmup and call counts with size at 256:

Warmup   Call   Time
------   ----   ----
32       1      24.23
32       8      20.30
32       16     19.43
0        32     17.14
0        64     16.91
0        96     17.78

Then I went tried max size of 128 and 64 using a warmup count of 0:

Call   Size  Time
----   ----  ----
1      128   22.8
32     128   17.1
64     128   16.97
96     128   17.76
32     64    19.7
64     64    19.25
96     64    19.25

Then, in search of a minima, I went through these valuse for call count with warmup of 0 and size of 128:

Call  Time
----  ----
40    17.23
44    16.48
45    16.44
46    16.51
48    16.56
50    16.65
52    16.73
56    16.57

These tests were all with a 6K code buffer. I rebuilt the VM with a 4K code buffer and got the same results.

With these values: warmup=0, call=45, size=128 I compiled a much larger program - the RPN calculator. It gives the compiler a nice workout. Again, the baseline and the 6K codebuffer version and 4K codebuffer version:

Test: +PLASM RPNCALC.PLA

Baseline PLASMA VM: 3:37.48
6K JIT VM: 1:57.92
4K JIT VM: 1:59.02

A 45% speed improvement for a 4K main memory codebuffer and a <10K JIT compiler (in aux memory) trade off. Not bad.

Of course there is much work to do. I'm still working out some of my optimization strategies involving the Y register. Might get a smidge better performance/density, but probably just a few percent best case. I'd also like to get the compiler closer to 8K in size.

Dave...

[toc] | [prev] | [next] | [standalone]

#4469

David Schmenk <dschmenk@gmail.com> wrote:
> After killing the last bug with the JIT, time to test out what it can really do.
> 
> As a quick review, the JIT compiler will recompile the PLASMA bytecode
> into ~optimized 6502 machine code. The JIT compiler source is cleaned up
> quite a bit. Worth checking out:
> https://github.com/dschmenk/PLASMA/blob/devel/src/libsrc/apple/jit.pla
> 
> There are three tunable parameters used by the VM to determine when to
> let the compiler take a swing at the bytecoded routine: Initialization
> warmup, runtime function call count, and function size. Another parameter
> isn't tuneable; the VM has to be built with the size of the destination
> codebuffer fixed-in. I wrote a little utility to adjust the tunable
> parameters from the command line so the effects can be easily measured
> without having to rebuild anything.
> 
> For my testing, I chose the PLASMA compiler, PLASM, and measured the time
> it took to compile the SIEVE.PLA benchmark. It is a pretty small program,
> but I measured the time from pressing enter to when the prompt returned.
> There is a lot of time taken to just load the module and dynamically link
> it which is the same regardless. Nevertheless, it was easier to measure
> the total time. I first did a baseline measurement with the standard
> bytecode interpreted PLASMA VM, then ran through a series of values to
> fid the best performance.
> 
> Test: +PLASM SIEVE.PLA
> 
> Baseline PLASMA VM: 18.8 seconds (average of 3 runs)
> 
> For the JIT compiler, the values iterated through were:
> Warmup count: 0, 32, 64, 128, 1024
> Then call count: 1, 8, 16, 32, 64, 96
> Then max size: 256, 128, 64
> 
> Since formatting the tabulated data will probably be a disaster, let me
> summerize the results. By far, the most important parameter is the call
> count. The warmup count only had small effect, and it was detrimental (it
> just slowed things down). Here are the best times for the combination of
> warmup and call counts with size at 256:
> 
> Warmup   Call   Time
> ------   ----   ----
> 32       1      24.23
> 32       8      20.30
> 32       16     19.43
> 0        32     17.14
> 0        64     16.91
> 0        96     17.78
> 
> Then I went tried max size of 128 and 64 using a warmup count of 0:
> 
> Call   Size  Time
> ----   ----  ----
> 1      128   22.8
> 32     128   17.1
> 64     128   16.97
> 96     128   17.76
> 32     64    19.7
> 64     64    19.25
> 96     64    19.25
> 
> Then, in search of a minima, I went through these valuse for call count
> with warmup of 0 and size of 128:
> 
> Call  Time
> ----  ----
> 40    17.23
> 44    16.48
> 45    16.44
> 46    16.51
> 48    16.56
> 50    16.65
> 52    16.73
> 56    16.57
> 
> These tests were all with a 6K code buffer. I rebuilt the VM with a 4K
> code buffer and got the same results.
> 
> With these values: warmup=0, callE, size8 I compiled a much larger
> program - the RPN calculator. It gives the compiler a nice workout.
> Again, the baseline and the 6K codebuffer version and 4K codebuffer version:
> 
> Test: +PLASM RPNCALC.PLA
> 
> Baseline PLASMA VM: 3:37.48
> 6K JIT VM: 1:57.92
> 4K JIT VM: 1:59.02
> 
> A 45% speed improvement for a 4K main memory codebuffer and a <10K JIT
> compiler (in aux memory) trade off. Not bad.
> 
> Of course there is much work to do. I'm still working out some of my
> optimization strategies involving the Y register. Might get a smidge better
> performance/density, but probably just a few percent best case. I'd also
> like to get the compiler closer to 8K in size.
> 
> Dave...
> 

Great work, Dave!

Have you considered providing the ability to “throw away” compiled
procedures?  

This would allow new code to be compiled, with the result that the compiled
code area becomes a cache, allowing LRU or other management techniques to
create a working set of compiled code. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#4471

On Wednesday, 28 March 2018 18:51:33 UTC-7, mjm...@aol.com  wrote:
> David Schmenk <dschmenk@gmail.com> wrote:
> > After killing the last bug with the JIT, time to test out what it can really do.
> > 
> > As a quick review, the JIT compiler will recompile the PLASMA bytecode
> > into ~optimized 6502 machine code. The JIT compiler source is cleaned up
> > quite a bit. Worth checking out:
> > https://github.com/dschmenk/PLASMA/blob/devel/src/libsrc/apple/jit.pla
> > 
> > There are three tunable parameters used by the VM to determine when to
> > let the compiler take a swing at the bytecoded routine: Initialization
> > warmup, runtime function call count, and function size. Another parameter
> > isn't tuneable; the VM has to be built with the size of the destination
> > codebuffer fixed-in. I wrote a little utility to adjust the tunable
> > parameters from the command line so the effects can be easily measured
> > without having to rebuild anything.
> > 
> > For my testing, I chose the PLASMA compiler, PLASM, and measured the time
> > it took to compile the SIEVE.PLA benchmark. It is a pretty small program,
> > but I measured the time from pressing enter to when the prompt returned.
> > There is a lot of time taken to just load the module and dynamically link
> > it which is the same regardless. Nevertheless, it was easier to measure
> > the total time. I first did a baseline measurement with the standard
> > bytecode interpreted PLASMA VM, then ran through a series of values to
> > fid the best performance.
> > 
> > Test: +PLASM SIEVE.PLA
> > 
> > Baseline PLASMA VM: 18.8 seconds (average of 3 runs)
> > 
> > For the JIT compiler, the values iterated through were:
> > Warmup count: 0, 32, 64, 128, 1024
> > Then call count: 1, 8, 16, 32, 64, 96
> > Then max size: 256, 128, 64
> > 
> > Since formatting the tabulated data will probably be a disaster, let me
> > summerize the results. By far, the most important parameter is the call
> > count. The warmup count only had small effect, and it was detrimental (it
> > just slowed things down). Here are the best times for the combination of
> > warmup and call counts with size at 256:
> > 
> > Warmup   Call   Time
> > ------   ----   ----
> > 32       1      24.23
> > 32       8      20.30
> > 32       16     19.43
> > 0        32     17.14
> > 0        64     16.91
> > 0        96     17.78
> > 
> > Then I went tried max size of 128 and 64 using a warmup count of 0:
> > 
> > Call   Size  Time
> > ----   ----  ----
> > 1      128   22.8
> > 32     128   17.1
> > 64     128   16.97
> > 96     128   17.76
> > 32     64    19.7
> > 64     64    19.25
> > 96     64    19.25
> > 
> > Then, in search of a minima, I went through these valuse for call count
> > with warmup of 0 and size of 128:
> > 
> > Call  Time
> > ----  ----
> > 40    17.23
> > 44    16.48
> > 45    16.44
> > 46    16.51
> > 48    16.56
> > 50    16.65
> > 52    16.73
> > 56    16.57
> > 
> > These tests were all with a 6K code buffer. I rebuilt the VM with a 4K
> > code buffer and got the same results.
> > 
> > With these values: warmup=0, callE, size 8 I compiled a much larger
> > program - the RPN calculator. It gives the compiler a nice workout.
> > Again, the baseline and the 6K codebuffer version and 4K codebuffer version:
> > 
> > Test: +PLASM RPNCALC.PLA
> > 
> > Baseline PLASMA VM: 3:37.48
> > 6K JIT VM: 1:57.92
> > 4K JIT VM: 1:59.02
> > 
> > A 45% speed improvement for a 4K main memory codebuffer and a <10K JIT
> > compiler (in aux memory) trade off. Not bad.
> > 
> > Of course there is much work to do. I'm still working out some of my
> > optimization strategies involving the Y register. Might get a smidge better
> > performance/density, but probably just a few percent best case. I'd also
> > like to get the compiler closer to 8K in size.
> > 
> > Dave...
> > 
> 
> Great work, Dave!
> 
> Have you considered providing the ability to “throw away” compiled
> procedures?  
> 
> This would allow new code to be compiled, with the result that the compiled
> code area becomes a cache, allowing LRU or other management techniques to
> create a working set of compiled code. 
> 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

Thanks Michael-

Now that I have some real data, many possibilities can be considered. I was surprised by the results in many ways.

First, I was getting worried when my initial runs were *much* slower than the baseline! In PLASMA, a module's main entry point/init routine never gets JIT compiled - it is supposed to be run once then thrown away (literally). That probably explains the uselessness of the warmup parameter. Then I expected the call count to improve the times much sooner than they did. I would have thought compiling routines up front would improve performance rather than waiting a while. There are definitely some interactions going on inside.

But what really threw me was the indifference to the code buffer size of 6K and 4K and the max routine size of 256 and 128 bytes. Of course this is only one real test case, but probably the most extensive and significant one I have. As such, I would be inclined to simply reserve the 4K code buffer and compile until it's filled up. Going with an LRU algorithm wouldn't be that hard, though. Since the compiler is simply a PLASMA routine, it has access to everything all the other PLASMA modules have access to, including a more sophisticated memory manager. But there is where the tradeoffs come in. In the absence of more real-world data, I'm going to keep it simple with a statically allocated 4K buffer

Fun stuff!

Dave...

[toc] | [prev] | [next] | [standalone]

#4473

On Thursday, March 29, 2018 at 10:17:33 AM UTC-4, David Schmenk wrote:
> Of course this is only one real test case, but probably the most extensive and significant one I have.

I imagine the Lawless Legends codebase might prove interesting. They also might be interested in periodically explicitly clearing out the entire JIT buffer -- say when the game changes modes -- and letting it fill up again more appropriately.

Zellyn

[toc] | [prev] | [next] | [standalone]

#4477

On Thursday, 29 March 2018 08:12:23 UTC-7, Zellyn  wrote:
> On Thursday, March 29, 2018 at 10:17:33 AM UTC-4, David Schmenk wrote:
> > Of course this is only one real test case, but probably the most extensive and significant one I have.
> 
> I imagine the Lawless Legends codebase might prove interesting. They also might be interested in periodically explicitly clearing out the entire JIT buffer -- say when the game changes modes -- and letting it fill up again more appropriately.
> 
> Zellyn

LL uses PLASMA in non-performance places - hard to measure the impact there. The code density and ability to execute from AUX memory is the greatest benefit. But maybe the follow on game...

[toc] | [prev] | [next] | [standalone]

#4470

David,

Not sure if this is appropriate, Is the Plasma codebase (once its operational) a speed demon?  Could it be benchmarked against output code created by Idiot Compiler.

I admit the "compile" process is atrociously slow but once its in machine code, its "ASM" fast.  Admittedly, Plasma "can/was" do a lot more functionality wise.

[toc] | [prev] | [next] | [standalone]

#4472

On Wednesday, 28 March 2018 23:02:47 UTC-7, Tom Porter  wrote:
> David,
> 
> Not sure if this is appropriate, Is the Plasma codebase (once its operational) a speed demon?  Could it be benchmarked against output code created by Idiot Compiler.
> 
> I admit the "compile" process is atrociously slow but once its in machine code, its "ASM" fast.  Admittedly, Plasma "can/was" do a lot more functionality wise.

Tom-

Great idea. One benchmark to consider is the Sieve of Eratosthenes. It is simple, integer math only, and does *something* in a meaningful amount of time (Unless you're John Brooks, then you have to run it a million times to be able to measure it). Do you have others in mind? 

Dave...

[toc] | [prev] | [next] | [standalone]

#4474

Been playing around with plasma and it's pretty cool. Having done some messing with Arduino, it's nice seeing the same functions (SPI, etc).

Side question; is there a way to read the real time clock via prodos? I suppose if you have SPI you could just hook something like a DS1302/DS3231 to the game port...

f

[toc] | [prev] | [next] | [standalone]

#4478

On Thursday, 29 March 2018 08:25:54 UTC-7, Frank M.  wrote:
> Been playing around with plasma and it's pretty cool. Having done some messing with Arduino, it's nice seeing the same functions (SPI, etc).
> 
> Side question; is there a way to read the real time clock via prodos? I suppose if you have SPI you could just hook something like a DS1302/DS3231 to the game port...
> 
> f

Glad you like it! Check out the end of this: https://www.youtube.com/watch?v=JocgWcenoPg

Dave...

[toc] | [prev] | [next] | [standalone]

#4486

That's awesome. Missed that one. I'll have to dig out my Uno and try that out. Pretty sure I have all the components. I can't seem to buy a working clock card/no-slot so that will have to do. Maybe I'll try and compile the plasma module into a nsclock.system-style prodos driver.

Any way to read the time via prodos? (lets say I did have a card). I see all the MLI calls except the time-related ones.

If one had a ethernet/wifi setup I supppose you could also poll ntp from somewhere (unfortunately, I don't have that card either).

F


On Thursday, March 29, 2018 at 8:25:54 AM UTC-7, Frank M. wrote:
> Been playing around with plasma and it's pretty cool. Having done some messing with Arduino, it's nice seeing the same functions (SPI, etc).
> 
> Side question; is there a way to read the real time clock via prodos? I suppose if you have SPI you could just hook something like a DS1302/DS3231 to the game port...
> 
> f

[toc] | [prev] | [next] | [standalone]

#4487

On 4/1/2018 7:48 AM, Frank M. wrote:
> 
> That's awesome. Missed that one. I'll have to dig out my Uno and try that out. Pretty sure I have all the components. I can't seem to buy a working clock card/no-slot so that will have to do. Maybe I'll try and compile the plasma module into a nsclock.system-style prodos driver.
> 
> Any way to read the time via prodos? (lets say I did have a card). I see all the MLI calls except the time-related ones.

If any ProDOS-compatible clock is present, ProDOS updates the time and 
date in memory on many disk accesses, and also on FLUSH, a relatively 
little used BASIC.SYSTEM command that flushes any unwritten buffers to disk.

In most cases, there are no unwritten buffers, so FLUSH takes a small 
fraction of a second to update the ProDOS time and date.

ProDOS stores the time and date in the global page at $BF90..$BF93 in 
the same format stored in directory entries.

If BASIC.SYSTEM is not present, the ProDOS MLI $82 call (GET_TIME) 
updates the time and date in the global page.

This should allow a short PLASMA routine to be written to return the 
time and/or date.  BTW, if the global page date or time is zero, then a 
ProDOS-compatible clock is not present.

> If one had a ethernet/wifi setup I supppose you could also poll ntp from somewhere (unfortunately, I don't have that card either).
> 
> F
> 
> 
> On Thursday, March 29, 2018 at 8:25:54 AM UTC-7, Frank M. wrote:
>> Been playing around with plasma and it's pretty cool. Having done some messing with Arduino, it's nice seeing the same functions (SPI, etc).
>>
>> Side question; is there a way to read the real time clock via prodos? I suppose if you have SPI you could just hook something like a DS1302/DS3231 to the game port...
>>
>> f
> 


-- 

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page: http://michaeljmahon.com

"The wastebasket is our most important design
tool--and it's seriously underused."

[toc] | [prev] | [next] | [standalone]

#4488

On 2018-04-01 15:12, Michael J. Mahon wrote:
 > if the global page date or time is zero,
 > then a ProDOS-compatible clock is not present.

Well, if the date is zero.
If the time is zero, it might just be midnight.  :)

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.apple2.programmer

csiph-web