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

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

PLASMA Developer Preview 1.0 Available:

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

Contents

  PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-17 06:57 -0800
    Re: PLASMA Developer Preview 1.0 Available: D Finnigan <dog_cow@macgui.com> - 2018-01-17 20:27 +0000
      Re: PLASMA Developer Preview 1.0 Available: Anthony Ortiz <anthonypaulo@gmail.com> - 2018-01-17 12:33 -0800
        Re: PLASMA Developer Preview 1.0 Available: Anthony Ortiz <anthonypaulo@gmail.com> - 2018-01-17 12:38 -0800
          Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-17 14:33 -0800
    Re: PLASMA Developer Preview 1.0 Available: cbmeeks <cbmeeks@gmail.com> - 2018-01-17 13:14 -0800
      Re: PLASMA Developer Preview 1.0 Available: ol.sc@web.de (Oliver Schmidt) - 2018-01-17 22:29 +0000
    Re: PLASMA Developer Preview 1.0 Available: John Brooks <jbrooks@blueshiftinc.com> - 2018-01-18 02:57 -0800
      Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-18 11:12 -0800
        Re: PLASMA Developer Preview 1.0 Available: John Brooks <jbrooks@blueshiftinc.com> - 2018-01-18 12:02 -0800
          Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-18 13:07 -0800
            Re: PLASMA Developer Preview 1.0 Available: John Brooks <jbrooks@blueshiftinc.com> - 2018-01-18 14:21 -0800
              Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-18 16:49 -0800
                Re: PLASMA Developer Preview 1.0 Available: John Brooks <jbrooks@blueshiftinc.com> - 2018-01-18 21:40 -0800
                  Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-19 09:06 -0800
                    Re: PLASMA Developer Preview 1.0 Available: John Brooks <jbrooks@blueshiftinc.com> - 2018-01-19 10:03 -0800
                      Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-19 13:24 -0800
                Re: PLASMA Developer Preview 1.0 Available: martin_haye <martin.haye@gmail.com> - 2018-01-21 11:24 -0800
                  Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-21 11:44 -0800
                    Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-21 11:47 -0800
                      Re: PLASMA Developer Preview 1.0 Available: John Brooks <jbrooks@blueshiftinc.com> - 2018-01-21 23:00 -0800
                        Re: PLASMA Developer Preview 1.0 Available: Steve Nickolas <usotsuki@buric.co> - 2018-01-22 05:06 -0500
                        Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-22 06:48 -0800
          Re: PLASMA Developer Preview 1.0 Available: Anthony Ortiz <anthonypaulo@gmail.com> - 2018-01-18 14:05 -0800
    Re: PLASMA Developer Preview 1.0 Available: mmphosis <mmphosis@macgui.com> - 2018-01-18 18:21 +0000
    Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-20 17:02 -0800
      Re: PLASMA Developer Preview 1.0 Available: John Brooks <jbrooks@blueshiftinc.com> - 2018-01-20 19:03 -0800
        Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-21 11:04 -0800
        Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-21 11:06 -0800
    Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-24 20:48 -0800
    Re: PLASMA Developer Preview 1.0 Available: David Schmenk <dschmenk@gmail.com> - 2018-01-26 14:49 -0800

Page 2 of 2 — ← Prev page 1 [2]

#4135

On Sunday, January 21, 2018 at 11:47:31 AM UTC-8, David Schmenk wrote:
> On Sunday, 21 January 2018 11:44:17 UTC-8, David Schmenk  wrote:
> > On Sunday, 21 January 2018 11:24:12 UTC-8, martin_haye  wrote:
> > > Loving this thread and very much looking forward to the speedup to Lawless Legends' PLASMA code (and there's a lot of it). I'm late to the party and probably won't stay long but the following stuck out:
> > > 
> > > > Simply remove the BNE NEXTOPH from FETCHOP, then rewrite INC_IP as:
> > > >         !MACRO  INC_IP  {
> > > >         INY
> > > >         BPL     +
> > > >         INC    IPH
> > > >         TYA
> > > >         AND     #$7F
> > > >         TAY
> > > > +
> > > >         }
> > > 
> > > This can't be right, can it? If there's a sequence of boring instructions say 130 bytes long, this will incorrectly jump to the next page and miss the last two instructions. Or am I reading it wrong?
> > > 
> > > Something like the following would do the trick I think:
> > > 
> > >  INY
> > >  BPL +
> > >  TYA
> > >  AND #$7F
> > >  TAY
> > >  LDA IPL
> > >  EOR #$80
> > >  STA IPL
> > >  BMI +
> > >  INC IPH
> > > +
> > > 
> > > --Martin
> > 
> > No, I had it wrong. I fixed it to be (flattens IP+Y):
> > 
> > !MACRO  FIXJMP_IP   .TARGET {
> >         BMI     +
> >         JMP     .TARGET
> > +       TYA
> >         CLC
> >         ADC     IPL
> >         STA     IPL
> >         BCC     +
> >         INC     IPH
> > +       LDY     #$00
> >         JMP     .TARGET
> >         }
> > 
> > It is preceded by INY and goes at the end of the opcode, which is why there is a target to jump to (NEXTOP or DROP for now). Good eye as always, Martin. I was originally going to say that LL wouldn't need an update of the VM, but it's going to be *really* good when 1.0 arrives.
> > 
> > Dave...
> 
> Oh, one other thing. I didn't catch it originally - I was a little excited to get it in to the VM, but the code never ran because no sequence of opcodes was long enough without a branch or call (which re-normalize the IP).
> 
> Dave...

Quick note: this would be smaller and likely faster

Old:

> !MACRO  FIXJMP_IP   .TARGET { 
>         BMI     + 
>         JMP     .TARGET 
> +       TYA 
>         CLC 
>         ADC     IPL 
>         STA     IPL 
>         BCC     + 
>         INC     IPH 
> +       LDY     #$00 
>         JMP     .TARGET 
>         } 

New:

> !MACRO  FIXJMP_IP   .TARGET { 
>         BMI     + 
> -       JMP     .TARGET 
> +       TYA 
>         LDY     #$00 
>         CLC 
>         ADC     IPL 
>         STA     IPL 
>         BCC     - 
>         INC     IPH 
>         BCS     - 
>         } 

-JB

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

#4136

I definitely need to learn Z80 so I can write interpreters for CP/M and 
MSX. XD

-uso.

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

#4137

On Sunday, 21 January 2018 23:00:34 UTC-8, John Brooks  wrote:
> On Sunday, January 21, 2018 at 11:47:31 AM UTC-8, David Schmenk wrote:
> > On Sunday, 21 January 2018 11:44:17 UTC-8, David Schmenk  wrote:
> > > On Sunday, 21 January 2018 11:24:12 UTC-8, martin_haye  wrote:
> > > > Loving this thread and very much looking forward to the speedup to Lawless Legends' PLASMA code (and there's a lot of it). I'm late to the party and probably won't stay long but the following stuck out:
> > > > 
> > > > > Simply remove the BNE NEXTOPH from FETCHOP, then rewrite INC_IP as:
> > > > >         !MACRO  INC_IP  {
> > > > >         INY
> > > > >         BPL     +
> > > > >         INC    IPH
> > > > >         TYA
> > > > >         AND     #$7F
> > > > >         TAY
> > > > > +
> > > > >         }
> > > > 
> > > > This can't be right, can it? If there's a sequence of boring instructions say 130 bytes long, this will incorrectly jump to the next page and miss the last two instructions. Or am I reading it wrong?
> > > > 
> > > > Something like the following would do the trick I think:
> > > > 
> > > >  INY
> > > >  BPL +
> > > >  TYA
> > > >  AND #$7F
> > > >  TAY
> > > >  LDA IPL
> > > >  EOR #$80
> > > >  STA IPL
> > > >  BMI +
> > > >  INC IPH
> > > > +
> > > > 
> > > > --Martin
> > > 
> > > No, I had it wrong. I fixed it to be (flattens IP+Y):
> > > 
> > > !MACRO  FIXJMP_IP   .TARGET {
> > >         BMI     +
> > >         JMP     .TARGET
> > > +       TYA
> > >         CLC
> > >         ADC     IPL
> > >         STA     IPL
> > >         BCC     +
> > >         INC     IPH
> > > +       LDY     #$00
> > >         JMP     .TARGET
> > >         }
> > > 
> > > It is preceded by INY and goes at the end of the opcode, which is why there is a target to jump to (NEXTOP or DROP for now). Good eye as always, Martin. I was originally going to say that LL wouldn't need an update of the VM, but it's going to be *really* good when 1.0 arrives.
> > > 
> > > Dave...
> > 
> > Oh, one other thing. I didn't catch it originally - I was a little excited to get it in to the VM, but the code never ran because no sequence of opcodes was long enough without a branch or call (which re-normalize the IP).
> > 
> > Dave...
> 
> Quick note: this would be smaller and likely faster
> 
> Old:
> 
> > !MACRO  FIXJMP_IP   .TARGET { 
> >         BMI     + 
> >         JMP     .TARGET 
> > +       TYA 
> >         CLC 
> >         ADC     IPL 
> >         STA     IPL 
> >         BCC     + 
> >         INC     IPH 
> > +       LDY     #$00 
> >         JMP     .TARGET 
> >         } 
> 
> New:
> 
> > !MACRO  FIXJMP_IP   .TARGET { 
> >         BMI     + 
> > -       JMP     .TARGET 
> > +       TYA 
> >         LDY     #$00 
> >         CLC 
> >         ADC     IPL 
> >         STA     IPL 
> >         BCC     - 
> >         INC     IPH 
> >         BCS     - 
> >         } 
> 
> -JB

I should really have just one (or two, depending on .target) re-normalize routine and have all the fix-ups jump to it. It never runs anyway, unless someone comes up with a pathological case. And, there are only a handful of places fix-ups are checked now.

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

#4121

I'm loving this thread... great stuff!

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

#4117

I like this language a lot.  I find the code beautiful: easy to read.

Even if it is not quite as fast, it doesn't matter because we just crank up
the speed of the emulator.  EX.9.PLA -- the forest fire is much more
readable than my 6502 assembly:  http://hoop-la.ca/apple2/2012/forestfire/

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

#4128

With the inclusion of most of the ideas thrown around here, and significant rewrite of the module loader to speed up the dynamic linking process, Developer Preview #2 is available: https://github.com/dschmenk/PLASMA/blob/master/doc/Preview%20Version%201.0.md

I really hadn't intended on releasing a DP#2, but there was just too much good stuff to let sit. I re-ran the sieve benchmark on DP#2, and it came in at 11.2% faster. To put this in perspective, the original PLASMA compiler could build a native 6502 executable (no bytecode). It was big, but fast. Eyeballing the performance of Rod's Colors with native code vs DP#2, it's not even twice as fast. Much of the time is spent in multiply and divide, but to have DP#2 be that close in performance and a fraction of the size is amazing.

DP#2 is actually usable on a 64K, floppy based system. Running the editor and compiler, even. Absolutely flies on a IIGS or accelerator and hard disk/CFFA.

Thanks again to all those that put so much of their time and effort into making this a reality.

Dave...

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

#4129

On Saturday, January 20, 2018 at 5:02:34 PM UTC-8, David Schmenk wrote:
> With the inclusion of most of the ideas thrown around here, and significant rewrite of the module loader to speed up the dynamic linking process, Developer Preview #2 is available: https://github.com/dschmenk/PLASMA/blob/master/doc/Preview%20Version%201.0.md
> 
> I really hadn't intended on releasing a DP#2, but there was just too much good stuff to let sit. I re-ran the sieve benchmark on DP#2, and it came in at 11.2% faster. To put this in perspective, the original PLASMA compiler could build a native 6502 executable (no bytecode). It was big, but fast. Eyeballing the performance of Rod's Colors with native code vs DP#2, it's not even twice as fast. Much of the time is spent in multiply and divide, but to have DP#2 be that close in performance and a fraction of the size is amazing.
> 
> DP#2 is actually usable on a 64K, floppy based system. Running the editor and compiler, even. Absolutely flies on a IIGS or accelerator and hard disk/CFFA.
> 
> Thanks again to all those that put so much of their time and effort into making this a reality.
> 
> Dave...

Very cool Dave!

Here are some more ideas to consider:

1) You can save VM code bytes by putting an INY after FETCHOP @ $F3, so all the multibyte opcode handlers don't have to start with an INY. However, single-byte opcodes that end with drop either need to do their own DEX before calling FETCHOP, or you could add a version of DROP that didn't do the extra NEXTOP INY.

Several handlers do a DEX which could be added to the next fetch as a PUSH, similar to how DROP is done now.

2) INCR & DECR can go one faster cycle by making the common path fall through:

Old:
INCR    INC     ESTKL,X
        BNE     INCR1
        INC     ESTKH,X
INCR1   JMP     NEXTOP

New:
INCR    INC     ESTKL,X
        BEQ     INCRHI
        JMP     NEXTOP
INCRHI   INC     ESTKH,X
        JMP     NEXTOP

3) Faster LNOT:

Old:
LNOT    LDA     ESTKL,X
        ORA     ESTKH,X
        BEQ     LNOT1
        LDA     #$FF
LNOT1   EOR     #$FF
        STA     ESTKL,X
        STA     ESTKH,X
        JMP     NEXTOP

New:
LNOT    LDA     ESTKL,X
        ORA     ESTKH,X
        BNE     ZERO
        LDA     #$FF
        STA     ESTKL,X
        STA     ESTKH,X
        JMP     NEXTOP

4) Faster CFFB:

Old:
CFFB    LDA     #$FF
        !BYTE $2C   ; BIT $00A9 - effectively skips LDA #$00, no harm in reading this address

New:
CFFB    LDA     #$FF
        ;DEX  ; Done later via PUSH
        STA     ESTKH-1,X ;-1 for PUSH
        ;INY ; done after FETCHOP
        LDA     (IP),Y
        STA     ESTKL,X
        JMP     PUSH ; DEX then FETCHOP

5) Faster LB & other eval stack load/store ops

Old:
LB      LDA     ESTKL,X
        STA     LBLDA+1
        LDA     ESTKH,X
        STA     LBLDA+2
LBLDA   LDA     $FFFF
        STA     ESTKL,X
        LDA     #$00
        STA     ESTKH,X
        JMP     NEXTOP

New:
LB      LDA     ESTKL,X
        STA     ESTKH-1,X ; Uses a pad byte between the ESTKL top & ESTKH btm 
        LDA     (ESTKH-1,X)
        STA     ESTKL,X
        LDA     #$00
        STA     ESTKH,X
        JMP     NEXTOP

6) Faster IsGE & other ISxx

Old:
ISGE    LDA     ESTKL+1,X
        CMP     ESTKL,X
        LDA     ESTKH+1,X
        SBC     ESTKH,X
        BVC     ISGE1
        EOR     #$80
ISGE1   BPL     ISTRU
        BMI     ISFLS

New:
ISGE    LDA     ESTKL+1,X
        CMP     ESTKL,X
        LDA     ESTKH+1,X
        SBC     ESTKH,X
        BVS     ISGE1
        BMI     ISFLS
        BPL     ISTRU
ISGE1   BMI     ISTRU
        BPL     ISFLS

7) Faster, smaller $00-$7F constants:

CONST
        STA     ESTKL-1,X
        LDA     #$00
        STA     ESTKH-1,X
        INY
PUSH
        DEX
        LDA     $FFFF,Y         ; FETCHOP @ $F3, IP MAPS OVER $FFFF @ $F4
        BPL     CONST
        INY
        STA     OPIDX
        JMP     (OPTBL-$80)         ; OP handler can BMI (from INY) for lazy IPH update

-JB
@JBrooksBSI

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

#4130

On Saturday, 20 January 2018 19:03:27 UTC-8, John Brooks  wrote:
> On Saturday, January 20, 2018 at 5:02:34 PM UTC-8, David Schmenk wrote:
> > With the inclusion of most of the ideas thrown around here, and significant rewrite of the module loader to speed up the dynamic linking process, Developer Preview #2 is available: https://github.com/dschmenk/PLASMA/blob/master/doc/Preview%20Version%201.0.md
> > 
> > I really hadn't intended on releasing a DP#2, but there was just too much good stuff to let sit. I re-ran the sieve benchmark on DP#2, and it came in at 11.2% faster. To put this in perspective, the original PLASMA compiler could build a native 6502 executable (no bytecode). It was big, but fast. Eyeballing the performance of Rod's Colors with native code vs DP#2, it's not even twice as fast. Much of the time is spent in multiply and divide, but to have DP#2 be that close in performance and a fraction of the size is amazing.
> > 
> > DP#2 is actually usable on a 64K, floppy based system. Running the editor and compiler, even. Absolutely flies on a IIGS or accelerator and hard disk/CFFA.
> > 
> > Thanks again to all those that put so much of their time and effort into making this a reality.
> > 
> > Dave...
> 


> Very cool Dave!
> 
> Here are some more ideas to consider:

Wow John - the hits keep coming!

> 
> 1) You can save VM code bytes by putting an INY after FETCHOP @ $F3, so all the multibyte opcode handlers don't have to start with an INY. However, single-byte opcodes that end with drop either need to do their own DEX before calling FETCHOP, or you could add a version of DROP that didn't do the extra NEXTOP INY.
> 
> Several handlers do a DEX which could be added to the next fetch as a PUSH, similar to how DROP is done now.
> 
> 2) INCR & DECR can go one faster cycle by making the common path fall through:
> 
> Old:
> INCR    INC     ESTKL,X
>         BNE     INCR1
>         INC     ESTKH,X
> INCR1   JMP     NEXTOP
> 
> New:
> INCR    INC     ESTKL,X
>         BEQ     INCRHI
>         JMP     NEXTOP
> INCRHI   INC     ESTKH,X
>         JMP     NEXTOP
> 
> 3) Faster LNOT:
> 
> Old:
> LNOT    LDA     ESTKL,X
>         ORA     ESTKH,X
>         BEQ     LNOT1
>         LDA     #$FF
> LNOT1   EOR     #$FF
>         STA     ESTKL,X
>         STA     ESTKH,X
>         JMP     NEXTOP
> 
> New:
> LNOT    LDA     ESTKL,X
>         ORA     ESTKH,X
>         BNE     ZERO
>         LDA     #$FF
>         STA     ESTKL,X
>         STA     ESTKH,X
>         JMP     NEXTOP
> 
> 4) Faster CFFB:
> 
> Old:
> CFFB    LDA     #$FF
>         !BYTE $2C   ; BIT $00A9 - effectively skips LDA #$00, no harm in reading this address
> 
> New:
> CFFB    LDA     #$FF
>         ;DEX  ; Done later via PUSH
>         STA     ESTKH-1,X ;-1 for PUSH
>         ;INY ; done after FETCHOP
>         LDA     (IP),Y
>         STA     ESTKL,X
>         JMP     PUSH ; DEX then FETCHOP
> 
> 5) Faster LB & other eval stack load/store ops
> 
> Old:
> LB      LDA     ESTKL,X
>         STA     LBLDA+1
>         LDA     ESTKH,X
>         STA     LBLDA+2
> LBLDA   LDA     $FFFF
>         STA     ESTKL,X
>         LDA     #$00
>         STA     ESTKH,X
>         JMP     NEXTOP
> 
> New:
> LB      LDA     ESTKL,X
>         STA     ESTKH-1,X ; Uses a pad byte between the ESTKL top & ESTKH btm 
>         LDA     (ESTKH-1,X)
>         STA     ESTKL,X
>         LDA     #$00
>         STA     ESTKH,X
>         JMP     NEXTOP

^^^^^^^^^
This. Is. Awesome. And deserves a description.
PLASMA was always going to be a stacked based architecture, but the implementation of the evaluation stack can go a few different ways. I ultimately chose a split, zero page stack indexed by the X register. The other option was to have a unified stack, but it would require adjusting the X register by two for every push and pop, but it allows one to use a stack entry as an address to indirectly fetch data.
I decided that the single INX/DEX for the split stack outweighed the indirect addressing of the unified stack, but required re-assembly of the address on the stack so it be referenced. We implemented a couple of approaches, each copying the tos of stack to another zero page word, or self-modifying code sequence. Neither was very satisfactory.
Now what John has shown, is that by moving the LSB of the stack entry to the empty spot right in front of the MSB, we get back the benefits of the unified stack with only a little bit of copying. And een better, we don't need to employ the Y register which is busy being part of our instruction pointer.
Time to rewrite large parts of the VM again, but oh, so worth it. I just have to swap where the LSB and MSB have of the stack exist so that the guard byte doesn't interfere with anything. 

> 
> 6) Faster IsGE & other ISxx
> 
> Old:
> ISGE    LDA     ESTKL+1,X
>         CMP     ESTKL,X
>         LDA     ESTKH+1,X
>         SBC     ESTKH,X
>         BVC     ISGE1
>         EOR     #$80
> ISGE1   BPL     ISTRU
>         BMI     ISFLS
> 
> New:
> ISGE    LDA     ESTKL+1,X
>         CMP     ESTKL,X
>         LDA     ESTKH+1,X
>         SBC     ESTKH,X
>         BVS     ISGE1
>         BMI     ISFLS
>         BPL     ISTRU
> ISGE1   BMI     ISTRU
>         BPL     ISFLS
> 
> 7) Faster, smaller $00-$7F constants:
> 
> CONST
>         STA     ESTKL-1,X
>         LDA     #$00
>         STA     ESTKH-1,X
>         INY
> PUSH
>         DEX
>         LDA     $FFFF,Y         ; FETCHOP @ $F3, IP MAPS OVER $FFFF @ $F4
>         BPL     CONST
>         INY
>         STA     OPIDX
>         JMP     (OPTBL-$80)         ; OP handler can BMI (from INY) for lazy IPH update
> 
> -JB
> @JBrooksBS

Man, I can hardly catch my breath from all these ideas. I have a feeling a DP#3 is in the works, especially with #5 neededing to rebuild any assembly interface code. But, I'm not complaining!

Dave...

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

#4131

On Saturday, 20 January 2018 19:03:27 UTC-8, John Brooks  wrote:
> On Saturday, January 20, 2018 at 5:02:34 PM UTC-8, David Schmenk wrote:
> > With the inclusion of most of the ideas thrown around here, and significant rewrite of the module loader to speed up the dynamic linking process, Developer Preview #2 is available: https://github.com/dschmenk/PLASMA/blob/master/doc/Preview%20Version%201.0.md
> > 
> > I really hadn't intended on releasing a DP#2, but there was just too much good stuff to let sit. I re-ran the sieve benchmark on DP#2, and it came in at 11.2% faster. To put this in perspective, the original PLASMA compiler could build a native 6502 executable (no bytecode). It was big, but fast. Eyeballing the performance of Rod's Colors with native code vs DP#2, it's not even twice as fast. Much of the time is spent in multiply and divide, but to have DP#2 be that close in performance and a fraction of the size is amazing.
> > 
> > DP#2 is actually usable on a 64K, floppy based system. Running the editor and compiler, even. Absolutely flies on a IIGS or accelerator and hard disk/CFFA.
> > 
> > Thanks again to all those that put so much of their time and effort into making this a reality.
> > 
> > Dave...
> 


> Very cool Dave!
> 
> Here are some more ideas to consider:

Wow John - the hits keep coming!


> 1) You can save VM code bytes by putting an INY after FETCHOP @ $F3, so all the multibyte opcode handlers don't have to start with an INY. However, single-byte opcodes that end with drop either need to do their own DEX before calling FETCHOP, or you could add a version of DROP that didn't do the extra NEXTOP INY.
> 
> Several handlers do a DEX which could be added to the next fetch as a PUSH, similar to how DROP is done now.
> 
> 2) INCR & DECR can go one faster cycle by making the common path fall through:
> 
> Old:
> INCR    INC     ESTKL,X
>         BNE     INCR1
>         INC     ESTKH,X
> INCR1   JMP     NEXTOP
> 
> New:
> INCR    INC     ESTKL,X
>         BEQ     INCRHI
>         JMP     NEXTOP
> INCRHI   INC     ESTKH,X
>         JMP     NEXTOP
> 
> 3) Faster LNOT:
> 
> Old:
> LNOT    LDA     ESTKL,X
>         ORA     ESTKH,X
>         BEQ     LNOT1
>         LDA     #$FF
> LNOT1   EOR     #$FF
>         STA     ESTKL,X
>         STA     ESTKH,X
>         JMP     NEXTOP
> 
> New:
> LNOT    LDA     ESTKL,X
>         ORA     ESTKH,X
>         BNE     ZERO
>         LDA     #$FF
>         STA     ESTKL,X
>         STA     ESTKH,X
>         JMP     NEXTOP
> 
> 4) Faster CFFB:
> 
> Old:
> CFFB    LDA     #$FF
>         !BYTE $2C   ; BIT $00A9 - effectively skips LDA #$00, no harm in reading this address
> 
> New:
> CFFB    LDA     #$FF
>         ;DEX  ; Done later via PUSH
>         STA     ESTKH-1,X ;-1 for PUSH
>         ;INY ; done after FETCHOP
>         LDA     (IP),Y
>         STA     ESTKL,X
>         JMP     PUSH ; DEX then FETCHOP
> 
> 5) Faster LB & other eval stack load/store ops
> 
> Old:
> LB      LDA     ESTKL,X
>         STA     LBLDA+1
>         LDA     ESTKH,X
>         STA     LBLDA+2
> LBLDA   LDA     $FFFF
>         STA     ESTKL,X
>         LDA     #$00
>         STA     ESTKH,X
>         JMP     NEXTOP
> 
> New:
> LB      LDA     ESTKL,X
>         STA     ESTKH-1,X ; Uses a pad byte between the ESTKL top & ESTKH btm 
>         LDA     (ESTKH-1,X)
>         STA     ESTKL,X
>         LDA     #$00
>         STA     ESTKH,X
>         JMP     NEXTOP

^^^^^^^^^

This. Is. Awesome. And deserves a description.
PLASMA was always going to be a stacked based architecture, but the implementation of the evaluation stack can go a few different ways. I ultimately chose a split, zero page stack indexed by the X register. The other option was to have a unified stack, but it would require adjusting the X register by two for every push and pop, but it allows one to use a stack entry as an address to indirectly fetch data.
I decided that the single INX/DEX for the split stack outweighed the indirect addressing of the unified stack, but required re-assembly of the address on the stack so it be referenced. We implemented a couple of approaches, each copying the tos of stack to another zero page word, or self-modifying code sequence. Neither was very satisfactory.
Now what John has shown, is that by moving the LSB of the stack entry to the empty spot right in front of the MSB, we get back the benefits of the unified stack with only a little bit of copying. And een better, we don't need to employ the Y register which is busy being part of our instruction pointer.
Time to rewrite large parts of the VM again, but oh, so worth it. I just have to swap where the LSB and MSB have of the stack exist so that the guard byte doesn't interfere with anything. 


> 6) Faster IsGE & other ISxx
> 
> Old:
> ISGE    LDA     ESTKL+1,X
>         CMP     ESTKL,X
>         LDA     ESTKH+1,X
>         SBC     ESTKH,X
>         BVC     ISGE1
>         EOR     #$80
> ISGE1   BPL     ISTRU
>         BMI     ISFLS
> 
> New:
> ISGE    LDA     ESTKL+1,X
>         CMP     ESTKL,X
>         LDA     ESTKH+1,X
>         SBC     ESTKH,X
>         BVS     ISGE1
>         BMI     ISFLS
>         BPL     ISTRU
> ISGE1   BMI     ISTRU
>         BPL     ISFLS
> 
> 7) Faster, smaller $00-$7F constants:
> 
> CONST
>         STA     ESTKL-1,X
>         LDA     #$00
>         STA     ESTKH-1,X
>         INY
> PUSH
>         DEX
>         LDA     $FFFF,Y         ; FETCHOP @ $F3, IP MAPS OVER $FFFF @ $F4
>         BPL     CONST
>         INY
>         STA     OPIDX
>         JMP     (OPTBL-$80)         ; OP handler can BMI (from INY) for lazy IPH update
> 
> -JB
> @JBrooksBS

Man, I can hardly catch my breath from all these ideas. I have a feeling a DP#3 is in the works, especially with #5 neededing to rebuild any assembly interface code. But, I'm not complaining!

Dave...

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

#4138

On Wednesday, 17 January 2018 06:57:55 UTC-8, David Schmenk  wrote:
> Modern Retroprogramming on the Apple II. When was the last time you programmed a modern language on a 40 year old computer? Now is your chance. PLASMA is a combination of operating environment, virtual machine, and assembler/compiler matched closely to the 6502 architecture. Check out the Release Notes for details: https://github.com/dschmenk/PLASMA/blob/master/doc/Preview%20Version%201.0.md

Feature Compleat (who played Oddysey?) Developer Preview #3. Includes all the project libraries and sample code. A music sequencer with MockingBoard support, TCP/IP drivers for the Uthernet (UDP only) and Uthernet2 (full TCP/IP).

And DP#3 is 12.8% faster that DP#1 thanks mostly to the ideas discussed here. Pretty amazing.

Same link as above for the Release Notes.

Dave...

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

#4145

I've created a YouTube channel for PLASMA. I'll fill in more episodes as I get time.

https://www.youtube.com/playlist?list=PLlPKgUMQbJ79VJvZRfv1CJQf4SP2Gw3yU

Dave...

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web