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

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

Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II D Finnigan <dog_cow@macgui.com> - 2016-07-19 22:35 +0000
    Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II Michael J. Mahon <mjmahon@aol.com> - 2016-07-19 23:28 -0500
      Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II John Brooks <jbrooks@blueshiftinc.com> - 2016-07-26 18:47 -0700
        Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-07-27 09:12 -0700
          Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II John Brooks <jbrooks@blueshiftinc.com> - 2016-07-27 17:39 -0700
            Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-07-28 10:30 -0700
      Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II John Brooks <jbrooks@blueshiftinc.com> - 2016-08-15 21:50 -0700
        Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II qkumba <peter.ferrie@gmail.com> - 2016-08-16 10:12 -0700
          Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II John Brooks <jbrooks@blueshiftinc.com> - 2016-08-16 14:28 -0700
            Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II qkumba <peter.ferrie@gmail.com> - 2016-08-16 15:52 -0700
              Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II John Brooks <jbrooks@blueshiftinc.com> - 2016-08-16 19:53 -0700
                Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II qkumba <peter.ferrie@gmail.com> - 2016-08-16 21:05 -0700
        Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II Michael J. Mahon <mjmahon@aol.com> - 2016-08-16 16:44 -0500
        Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II gids.rs@sasktel.net - 2016-08-16 22:16 -0700
          Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II Antoine Vignau <antoine.vignau@laposte.net> - 2016-08-17 08:20 -0700
            Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II qkumba <peter.ferrie@gmail.com> - 2016-08-17 10:09 -0700
            Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-08-17 11:35 -0700
        Re: Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II John Brooks <jbrooks@blueshiftinc.com> - 2016-08-17 23:00 -0700

#2842 — Assembler optimizations, was Re: Booting the right ProDOS 8 for any Apple II

Michael 'AppleWin Debugger Dev' wrote:
> On Tuesday, July 19, 2016 at 2:10:09 PM UTC-7, Michael J. Mahon wrote:
> 
>> You want a macro smart enough to peephole optimize redundant LDA #0's
>> away,
>> and to choose an unneeded register when available--more than most macros
>> can handle. 
>> 
> 
> Ideally, yes, but considering the 6502 assemblers are pretty dumb with
> optimizations (as far as I know they don't do any) 

Nor should they, I daresay.

[toc] | [next] | [standalone]

#2843

D Finnigan <dog_cow@macgui.com> wrote:
> Michael 'AppleWin Debugger Dev' wrote:
>> On Tuesday, July 19, 2016 at 2:10:09 PM UTC-7, Michael J. Mahon wrote:
>> 
>>> You want a macro smart enough to peephole optimize redundant LDA #0's
>>> away,
>>> and to choose an unneeded register when available--more than most macros
>>> can handle. 
>>> 
>> 
>> Ideally, yes, but considering the 6502 assemblers are pretty dumb with
>> optimizations (as far as I know they don't do any) 
> 
> Nor should they, I daresay.

I agree, but cleverly designed macros can actually convert an assembler
into a simple compiler. I've used the (annoyingly weak) Merlin macro
capability to create assemblers for the Floating Point Engine and even an
old word-oriented decimal machine (the Burroughs B220). 

But I agree that converting ProDOS is not the appropriate situation for
such an extension.

A good programmer can exploit opportunities to eliminate the use of 65C02
instructions at little or no cost in time or space, sometimes locally
rewriting code in the process. 

In the case of ProDOS, it is not particularly tightly written, so saving
space (and even time) while eliminating the 65C02 dependencies seems
feasible. 

I've written a lot of 6502 code, and I rarely find a situation where I
could do much better with 65C02 extensions. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#2844

>> I rarely find a situation where I could do much better with 65C02 extensions. 

Turns out that 65c02 is helping ProDOS 2.x a fair amount, at least as far as packing a lot of code ino the language card:

31x BRA instead of JMP
63x STZ instead of LDA #0, STA
18x  PHX/PHY instead of TXA/TYA, PHA. Same for PLX/PLY
2x LDA (dp) instead of LDY #0, LDA (dp),y
9x INC A, DEC A instead of CLC/SEC, ADC #1, SBC #1
5x TSB/TRB instead of LDA, AND/OR, STA

So Prodos is saving about 200 bytes with 65c02 opcodes, out of ~8K.

So about 2.5% savings. Though to be fair, much of the 8k is not code but tables & buffers.

-JB

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

#2845

On Tuesday, July 26, 2016 at 6:47:05 PM UTC-7, John Brooks wrote:

> So Prodos is saving about 200 bytes with 65c02 opcodes, out of ~8K.
> 
> So about 2.5% savings. Though to be fair, much of the 8k is not code but tables & buffers.

John, you wouldn't happen to have an estimate of the percentage of code to data by chance?
TIA

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

#2846

On Wednesday, July 27, 2016 at 9:12:02 AM UTC-7, Michael Pohoreski wrote:
> On Tuesday, July 26, 2016 at 6:47:05 PM UTC-7, John Brooks wrote:
> 
> > So Prodos is saving about 200 bytes with 65c02 opcodes, out of ~8K.
> > 
> > So about 2.5% savings. Though to be fair, much of the 8k is not code but tables & buffers.
> 
> John, you wouldn't happen to have an estimate of the percentage of code to data by chance?
> TIA

The main MLI code runs from $DE00-$FEFF. It contains 24 bytes of data at $DFE0 and 401 bytes of data at $FD6F-$FEFF.

= 425 bytes of data out of 8448 bytes = 5% data, 95% 65c02 code.

-JB

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

#2850

On Wednesday, July 27, 2016 at 5:39:49 PM UTC-7, John Brooks wrote:
> The main MLI code runs from $DE00-$FEFF. It contains 24 bytes of data at $DFE0 and 401 bytes of data at $FD6F-$FEFF.
> = 425 bytes of data out of 8448 bytes = 5% data, 95% 65c02 code.

Thanks!

Guess I'll have to do this for DOS 3.3 since I'm curious about the code:data ratio. :-)

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

#2949

On Tuesday, July 19, 2016 at 9:28:51 PM UTC-7, mjm...@aol.com wrote:
> D Finnigan wrote:
> > Michael 'AppleWin Debugger Dev' wrote:
> >> On Tuesday, July 19, 2016 at 2:10:09 PM UTC-7, Michael J. Mahon wrote:
> >> 
> >>> You want a macro smart enough to peephole optimize redundant LDA #0's
> >>> away,
> >>> and to choose an unneeded register when available--more than most macros
> >>> can handle. 
> >>> 
> >> 
> >> Ideally, yes, but considering the 6502 assemblers are pretty dumb with
> >> optimizations (as far as I know they don't do any) 
> > 
> > Nor should they, I daresay.
> 
> I agree, but cleverly designed macros can actually convert an assembler
> into a simple compiler. I've used the (annoyingly weak) Merlin macro
> capability to create assemblers for the Floating Point Engine and even an
> old word-oriented decimal machine (the Burroughs B220). 
> 
> But I agree that converting ProDOS is not the appropriate situation for
> such an extension.
> 
> A good programmer can exploit opportunities to eliminate the use of 65C02
> instructions at little or no cost in time or space, sometimes locally
> rewriting code in the process. 
> 
> In the case of ProDOS, it is not particularly tightly written, so saving
> space (and even time) while eliminating the 65C02 dependencies seems
> feasible. 
> 
> I've written a lot of 6502 code, and I rarely find a situation where I
> could do much better with 65C02 extensions. 
> -- 
> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

Here is a 65c02 code segment which is tricky to convert to 6502. It's from ProDOS 2.0.3 which is parsing a pathname, calculating the length of each name in the path and validating that each name is 15 chars or less in length:

* branches here when a '/' is found in the pathname.
* X&Y need to be preserved (X=path depth, Y=path char index)
GotSlash
  lda  NameLen
  cmp  #16
  bcs  Error

  phx
  ldx NamePtr
  sta Path,x ; Replace slash before the name with name length
  plx
  bne NextName  ; Loop if not last slash

  clc
...
Exit

When I converted this logic to 6502, the phx/ldx/sta/plx code sequence bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if there is a more compact alternative?

-JB

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

#2951

> Here is a 65c02 code segment which is tricky to convert to 6502. It's from ProDOS 2.0.3 which is parsing a pathname, calculating the length of each name in the path and validating that each name is 15 chars or less in length:
> 
> * branches here when a '/' is found in the pathname.
> * X&Y need to be preserved (X=path depth, Y=path char index)
> GotSlash
>   lda  NameLen
>   cmp  #16
>   bcs  Error
> 
>   phx
>   ldx NamePtr
>   sta Path,x ; Replace slash before the name with name length
>   plx
>   bne NextName  ; Loop if not last slash
> 
>   clc
> ...
> Exit
> 
> When I converted this logic to 6502, the phx/ldx/sta/plx code sequence bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if there is a more compact alternative?

What prevents stx $xx/ldx $xx instead of phx/plx?

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

#2952

On Tuesday, August 16, 2016 at 10:12:48 AM UTC-7, qkumba wrote:
> > Here is a 65c02 code segment which is tricky to convert to 6502. It's from ProDOS 2.0.3 which is parsing a pathname, calculating the length of each name in the path and validating that each name is 15 chars or less in length:
> > 
> > * branches here when a '/' is found in the pathname.
> > * X&Y need to be preserved (X=path depth, Y=path char index)
> > GotSlash
> >   lda  NameLen
> >   cmp  #16
> >   bcs  Error
> > 
> >   phx
> >   ldx NamePtr
> >   sta Path,x ; Replace slash before the name with name length
> >   plx
> >   bne NextName  ; Loop if not last slash
> > 
> >   clc
> > ...
> > Exit
> > 
> > When I converted this logic to 6502, the phx/ldx/sta/plx code sequence bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if there is a more compact alternative?
> 
> What prevents stx $xx/ldx $xx instead of phx/plx?

But where is a safe place to store X? This code is run during a ProDOS call, so the user app owns the lower 48k memory. It's also executing out of write-protected language card, so self-mod or function-local vars are out.

Right now I'm doing a dance of death to get X to and from the stack. I'll see if I can find a writeable temp somewhere (maybe I can use a ProDOS-owned zero page address).

-JB

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

#2954

On Tuesday, August 16, 2016 at 2:28:41 PM UTC-7, John Brooks wrote:
> On Tuesday, August 16, 2016 at 10:12:48 AM UTC-7, qkumba wrote:
> > > Here is a 65c02 code segment which is tricky to convert to 6502. It's from ProDOS 2.0.3 which is parsing a pathname, calculating the length of each name in the path and validating that each name is 15 chars or less in length:
> > > 
> > > * branches here when a '/' is found in the pathname.
> > > * X&Y need to be preserved (X=path depth, Y=path char index)
> > > GotSlash
> > >   lda  NameLen
> > >   cmp  #16
> > >   bcs  Error
> > > 
> > >   phx
> > >   ldx NamePtr
> > >   sta Path,x ; Replace slash before the name with name length
> > >   plx
> > >   bne NextName  ; Loop if not last slash
> > > 
> > >   clc
> > > ...
> > > Exit
> > > 
> > > When I converted this logic to 6502, the phx/ldx/sta/plx code sequence bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if there is a more compact alternative?
> > 
> > What prevents stx $xx/ldx $xx instead of phx/plx?
> 
> But where is a safe place to store X? This code is run during a ProDOS call, so the user app owns the lower 48k memory.

Something in the $4x range, perhaps.

> It's also executing out of write-protected language card, so self-mod or function-local vars are out.

Is it write-protected?  The MLI accesses $C08B before jumping into $DE00.  That's writable.

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

#2956

On Tuesday, August 16, 2016 at 3:52:02 PM UTC-7, qkumba wrote:
> On Tuesday, August 16, 2016 at 2:28:41 PM UTC-7, John Brooks wrote:
> > On Tuesday, August 16, 2016 at 10:12:48 AM UTC-7, qkumba wrote:
> > > > Here is a 65c02 code segment which is tricky to convert to 6502. It's from ProDOS 2.0.3 which is parsing a pathname, calculating the length of each name in the path and validating that each name is 15 chars or less in length:
> > > > 
> > > > * branches here when a '/' is found in the pathname.
> > > > * X&Y need to be preserved (X=path depth, Y=path char index)
> > > > GotSlash
> > > >   lda  NameLen
> > > >   cmp  #16
> > > >   bcs  Error
> > > > 
> > > >   phx
> > > >   ldx NamePtr
> > > >   sta Path,x ; Replace slash before the name with name length
> > > >   plx
> > > >   bne NextName  ; Loop if not last slash
> > > > 
> > > >   clc
> > > > ...
> > > > Exit
> > > > 
> > > > When I converted this logic to 6502, the phx/ldx/sta/plx code sequence bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if there is a more compact alternative?
> > > 
> > > What prevents stx $xx/ldx $xx instead of phx/plx?
> > 
> > But where is a safe place to store X? This code is run during a ProDOS call, so the user app owns the lower 48k memory.
> 
> Something in the $4x range, perhaps.
> 
> > It's also executing out of write-protected language card, so self-mod or function-local vars are out.
> 
> Is it write-protected?  The MLI accesses $C08B before jumping into $DE00.  That's writable.

There are multiple places where bank switching occurs and I haven't checked to see if LC is writable in all paths. I'll check that next though as adding an extra temp is probably the safest alternative to the stack approach I'm using now.

-JB

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

#2957

> > Is it write-protected?  The MLI accesses $C08B before jumping into $DE00.  That's writable.
> 
> There are multiple places where bank switching occurs and I haven't checked to see if LC is writable in all paths. I'll check that next though as adding an extra temp is probably the safest alternative to the stack approach I'm using now.

The Path is in the $Fxxx range so the whole thing must be writable.
If at the place where NamePtr is stored, you also store the Path index, the phx/plx goes away and you actually save two bytes. i.e.

  stx  NamePtr ;assuming that this is even needed
  stx  PathPtr+1
  ...
GotSlash 
  lda  NameLen 
  cmp  #16 
  bcs  Error 

PathPtr
  sta Path ; Replace slash before the name with name length 
  bne NextName  ; Loop if not last slash 

  clc 
... 
Exit 

because Path is page-aligned, so you only need the offset within the page.

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

#2953

John Brooks <jbrooks@blueshiftinc.com> wrote:
> On Tuesday, July 19, 2016 at 9:28:51 PM UTC-7, mjm...@aol.com wrote:
>> D Finnigan wrote:
>>> Michael 'AppleWin Debugger Dev' wrote:
>>>> On Tuesday, July 19, 2016 at 2:10:09 PM UTC-7, Michael J. Mahon wrote:
>>>> 
>>>>> You want a macro smart enough to peephole optimize redundant LDA #0's
>>>>> away,
>>>>> and to choose an unneeded register when available--more than most macros
>>>>> can handle. 
>>>>> 
>>>> 
>>>> Ideally, yes, but considering the 6502 assemblers are pretty dumb with
>>>> optimizations (as far as I know they don't do any) 
>>> 
>>> Nor should they, I daresay.
>> 
>> I agree, but cleverly designed macros can actually convert an assembler
>> into a simple compiler. I've used the (annoyingly weak) Merlin macro
>> capability to create assemblers for the Floating Point Engine and even an
>> old word-oriented decimal machine (the Burroughs B220). 
>> 
>> But I agree that converting ProDOS is not the appropriate situation for
>> such an extension.
>> 
>> A good programmer can exploit opportunities to eliminate the use of 65C02
>> instructions at little or no cost in time or space, sometimes locally
>> rewriting code in the process. 
>> 
>> In the case of ProDOS, it is not particularly tightly written, so saving
>> space (and even time) while eliminating the 65C02 dependencies seems
>> feasible. 
>> 
>> I've written a lot of 6502 code, and I rarely find a situation where I
>> could do much better with 65C02 extensions. 
>> -- 
>> -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> Here is a 65c02 code segment which is tricky to convert to 6502. It's
> from ProDOS 2.0.3 which is parsing a pathname, calculating the length of
> each name in the path and validating that each name is 15 chars or less in length:
> 
> * branches here when a '/' is found in the pathname.
> * X&Y need to be preserved (X=path depth, Y=path char index)
> GotSlash
>   lda  NameLen
>   cmp  #16
>   bcs  Error
> 
>   phx
>   ldx NamePtr
>   sta Path,x ; Replace slash before the name with name length
>   plx
>   bne NextName  ; Loop if not last slash
> 
>   clc
> ...
> Exit
> 
> When I converted this logic to 6502, the phx/ldx/sta/plx code sequence
> bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if
> there is a more compact alternative?
> 
> -JB
> 

The simplest approach would be to store X in a directly-addressable temp,
assuming that reentrancy is not a requirement. 

It's quite common that a temp location is currently free, hopefully even on
page zero. 
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#2958

On Monday, August 15, 2016 at 10:51:00 PM UTC-6, John Brooks wrote:
> On Tuesday, July 19, 2016 at 9:28:51 PM UTC-7, mjm...@aol.com wrote:
> > D Finnigan wrote:
> > > Michael 'AppleWin Debugger Dev' wrote:
> > >> On Tuesday, July 19, 2016 at 2:10:09 PM UTC-7, Michael J. Mahon wrote:
> > >> 
> > >>> You want a macro smart enough to peephole optimize redundant LDA #0's
> > >>> away,
> > >>> and to choose an unneeded register when available--more than most macros
> > >>> can handle. 
> > >>> 
> > >> 
> > >> Ideally, yes, but considering the 6502 assemblers are pretty dumb with
> > >> optimizations (as far as I know they don't do any) 
> > > 
> > > Nor should they, I daresay.
> > 
> > I agree, but cleverly designed macros can actually convert an assembler
> > into a simple compiler. I've used the (annoyingly weak) Merlin macro
> > capability to create assemblers for the Floating Point Engine and even an
> > old word-oriented decimal machine (the Burroughs B220). 
> > 
> > But I agree that converting ProDOS is not the appropriate situation for
> > such an extension.
> > 
> > A good programmer can exploit opportunities to eliminate the use of 65C02
> > instructions at little or no cost in time or space, sometimes locally
> > rewriting code in the process. 
> > 
> > In the case of ProDOS, it is not particularly tightly written, so saving
> > space (and even time) while eliminating the 65C02 dependencies seems
> > feasible. 
> > 
> > I've written a lot of 6502 code, and I rarely find a situation where I
> > could do much better with 65C02 extensions. 
> > -- 
> > -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> Here is a 65c02 code segment which is tricky to convert to 6502. It's from ProDOS 2.0.3 which is parsing a pathname, calculating the length of each name in the path and validating that each name is 15 chars or less in length:
> 
> * branches here when a '/' is found in the pathname.
> * X&Y need to be preserved (X=path depth, Y=path char index)
> GotSlash
>   lda  NameLen
>   cmp  #16
>   bcs  Error
> 
>   phx
>   ldx NamePtr
>   sta Path,x ; Replace slash before the name with name length
>   plx
>   bne NextName  ; Loop if not last slash
> 
>   clc
> ...
> Exit
> 
> When I converted this logic to 6502, the phx/ldx/sta/plx code sequence bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if there is a more compact alternative?
> 
> -JB


This way adds 3 bytes

GotSlash
   txa
   ldx  NameLen
   cpx  #16
   bcs  Error
 
   pha
   txa
   ldx NamePtr
   sta Path,x ; Replace slash before the name with name length
   pla
   tax
   bne NextName  ; Loop if not last slash

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

#2961

ProDOS saves some ZP values on entry, it also saves register values, I'm sure you can use one of them

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

#2963

> ProDOS saves some ZP values on entry, it also saves register values, I'm sure you can use one of them

The registers are in active use at the time of that routine, so they must be either saved at that moment, or avoided entirely, e.g. via self-mod.

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

#2964

On Wednesday, August 17, 2016 at 8:20:35 AM UTC-7, Antoine Vignau wrote:
> ProDOS saves some ZP values on entry, it also saves register values, I'm sure you can use one of them

And here I was going to suggest using one of the many unused locations in the GLOBALS $BF page, such as $BFF6 .. $BFFC.

You could over-write some of the unused verions. :-)

* ibakver
* kbackver

BFEB:2C 8B C0   irqent      bit ramin
BFEE:2C 8B C0               bit ramin
BFF1:3C 3D DF               jmp irqrecev
BFF4:4C         bnkbyt1     dfb $00
BFF5:6F         bnkbte2     dfb $00
BFF6:00 00                  ds $bffc-*,0
BFF8:00 00
BFFA:04                             ; [Michael: ???]
BFFB:00
BFFC:00         ibakver     dfb $00 ; reserved [Michael: For what?]
BFFD:05         iversion    dfb $00
BFFE:00         kbakver     dfb $00 ; undefined: reserved for future use
BFFF:23         kversion    dfb $23 ; ProDOS 2.0.3

Another option might be:

* mliactv

for non-zero values.

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

#2971

On Monday, August 15, 2016 at 9:51:00 PM UTC-7, John Brooks wrote:
> On Tuesday, July 19, 2016 at 9:28:51 PM UTC-7, mjm...@aol.com wrote:
> > D Finnigan wrote:
> > > Michael 'AppleWin Debugger Dev' wrote:
> > >> On Tuesday, July 19, 2016 at 2:10:09 PM UTC-7, Michael J. Mahon wrote:
> > >> 
> > >>> You want a macro smart enough to peephole optimize redundant LDA #0's
> > >>> away,
> > >>> and to choose an unneeded register when available--more than most macros
> > >>> can handle. 
> > >>> 
> > >> 
> > >> Ideally, yes, but considering the 6502 assemblers are pretty dumb with
> > >> optimizations (as far as I know they don't do any) 
> > > 
> > > Nor should they, I daresay.
> > 
> > I agree, but cleverly designed macros can actually convert an assembler
> > into a simple compiler. I've used the (annoyingly weak) Merlin macro
> > capability to create assemblers for the Floating Point Engine and even an
> > old word-oriented decimal machine (the Burroughs B220). 
> > 
> > But I agree that converting ProDOS is not the appropriate situation for
> > such an extension.
> > 
> > A good programmer can exploit opportunities to eliminate the use of 65C02
> > instructions at little or no cost in time or space, sometimes locally
> > rewriting code in the process. 
> > 
> > In the case of ProDOS, it is not particularly tightly written, so saving
> > space (and even time) while eliminating the 65C02 dependencies seems
> > feasible. 
> > 
> > I've written a lot of 6502 code, and I rarely find a situation where I
> > could do much better with 65C02 extensions. 
> > -- 
> > -michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
> 
> Here is a 65c02 code segment which is tricky to convert to 6502. It's from ProDOS 2.0.3 which is parsing a pathname, calculating the length of each name in the path and validating that each name is 15 chars or less in length:
> 
> * branches here when a '/' is found in the pathname.
> * X&Y need to be preserved (X=path depth, Y=path char index)
> GotSlash
>   lda  NameLen
>   cmp  #16
>   bcs  Error
> 
>   phx
>   ldx NamePtr
>   sta Path,x ; Replace slash before the name with name length
>   plx
>   bne NextName  ; Loop if not last slash
> 
>   clc
> ...
> Exit
> 
> When I converted this logic to 6502, the phx/ldx/sta/plx code sequence bloated from 4 to 7 insn and from 8 bytes to 13 bytes. Any ideas on if there is a more compact alternative?
> 
> -JB

The stack-based save/restore code is 13 bytes:
  txa
  pha
  ldx NamePtr
  lda  NameLen
  sta Path,x ; Replace slash before the name with name length
  pla
  tax

I'm currently using a stx/ldx alternative which is also 13 bytes but faster (12 bytes code 1 byte temp).
  stx MiscTmp
  ldx NamePtr
  sta Path,x ; Replace slash before the name with name length
  ldx MiscTmp
  
If I use a temp byte in $BFxx as Michael suggested, it would save 1 byte. Using a $4x ZP temp would save 2 more code bytes, so best case is 10 bytes 6502 vs 8 bytes 65c02.

[toc] | [prev] | [standalone]

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

csiph-web