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

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

Efficient sign extension.

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

Contents

  Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-01 18:02 -0700
    Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-01 18:18 -0700
    Efficient sign extension. gids.rs@sasktel.net - 2020-04-02 14:27 -0700
      Re: Efficient sign extension. Andy McFadden <thefadden@gmail.com> - 2020-04-02 17:41 -0700
        Re: Efficient sign extension. John Brooks <jbrooks@blueshiftinc.com> - 2020-04-02 21:41 -0700
        Re: Efficient sign extension. gids.rs@sasktel.net - 2020-04-02 21:50 -0700
        Re: Efficient sign extension. gids.rs@sasktel.net - 2020-04-02 22:29 -0700
          Re: Efficient sign extension. Andy McFadden <thefadden@gmail.com> - 2020-04-03 08:08 -0700
            Re: Efficient sign extension. gids.rs@sasktel.net - 2020-04-03 09:15 -0700
        Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-03 22:44 -0700
      Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-03 08:24 -0700
        Re: Efficient sign extension. gids.rs@sasktel.net - 2020-04-03 09:23 -0700
          Re: Efficient sign extension. qkumba <peter.ferrie@gmail.com> - 2020-04-03 10:12 -0700
            Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-03 12:41 -0700
          Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-03 12:24 -0700
            Re: Efficient sign extension. gids.rs@sasktel.net - 2020-04-03 14:19 -0700
              Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-03 14:26 -0700
                Re: Efficient sign extension. gids.rs@sasktel.net - 2020-04-05 10:10 -0700
                  Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-05 10:43 -0700
                    Re: Efficient sign extension. gids.rs@sasktel.net - 2020-04-05 19:39 -0700
                      Re: Efficient sign extension. Michael Barry <barrym95838@yahoo.com> - 2020-04-05 20:17 -0700

Page 1 of 2  [1] 2  Next page →

#5458 — Efficient sign extension.

I was wandering the 'net and somehow kept noticing that more than a few 65xx programmers were taking more effort than necessary to sign-extend integers.  I've been playing with 65xx assembly for at least 39 years, and I really can't remember if I got this little ditty from somewhere else long ago and simply forgot from where, or if it's an original idea of mine.  Either way, here it is, all ten bytes and 13 cycles worth:

; Sign-extend A to 16-bits in L,H
    sta  L
    lda  #$7f
    cmp  L    ; cc for <0, cs for >=0
    sbc  #$7f
    sta  H    ; $ff for <0, $00 for >=0

Comments, critiques, suggestions, insults?

Mike B.

[toc] | [next] | [standalone]

#5459

; Promote (little-endian) int16 in N to int32
    lda  #$7f
    cmp  N+1  ; cc for <0, cs for >=0
    sbc  #$7f
    sta  N+2  ; $ff for <0, $00 for >=0
    sta  N+3

Mike B.

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

#5460

Is this like an April Fools’s joke?

Who are all these 6502 programmers writing new code?

And I don’t see where your code can be used in anything I have written.

If I wanted a signed integer I would just take the hi-bit of the hi-byte.

LDA HI
ASL

I haven’t delved into The Floating Point of Applesoft as much as I would have liked where I think it was done the most.  The article turning fractions into integers and vice versa has got more my attention.

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

#5461

On Thursday, April 2, 2020 at 2:27:47 PM UTC-7, gid...@sasktel.net wrote:
> If I wanted a signed integer I would just take the hi-bit of the hi-byte.
> 
> LDA HI
> ASL

The point is to convert a signed 8-bit value into a signed 16-bit value.   Stellar 7 does some of this in its graphics engine, e.g.:

                ldx     #$00              ;assume positive
                lda     view_x_adjs,y
                bpl     L616D
                dex                       ;sign-extend negative
L616D           sta     VIEW_X_ADJ
                stx     VIEW_X_ADJ+1

(from https://6502disassembly.com/a2-stellar7/ROCK2.html , at $6165)

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

#5462

On Thursday, April 2, 2020 at 5:41:38 PM UTC-7, Andy McFadden wrote:
> On Thursday, April 2, 2020 at 2:27:47 PM UTC-7, gid...@sasktel.net wrote:
> > If I wanted a signed integer I would just take the hi-bit of the hi-byte.
> > 
> > LDA HI
> > ASL
> 
> The point is to convert a signed 8-bit value into a signed 16-bit value.   Stellar 7 does some of this in its graphics engine, e.g.:
> 
>                 ldx     #$00              ;assume positive
>                 lda     view_x_adjs,y
>                 bpl     L616D
>                 dex                       ;sign-extend negative
> L616D           sta     VIEW_X_ADJ
>                 stx     VIEW_X_ADJ+1
> 
> (from https://6502disassembly.com/a2-stellar7/ROCK2.html , at $6165)

If you are going to do a lot of them, go for a lookup table:

                 ldx     view_x_adjs,y
                 lda     sign_extend,x
                 stx     VIEW_X_ADJ
                 sta     VIEW_X_ADJ+1

My first published game was a 3D flight sim on the Apple IIe. It rocked a frame rate of 1 FPS. How far we have come.  :)

-JB

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

#5463

I think I need a more general explanation than this game uses it or that game does it.

I know what the routine does, but to what purpose?

Does it make math calculations easier, but not necessarily faster?
Does it speed up screen draws?
... etc.

It is probably not how I would write code initially, but if I can see any benefits of it, I would definitely adopt it.

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

#5464

Looking at the Stellar7 code has got me even more confused as the view_x_adj+1 isn’t even used after the sign gets stored in it.

And I only see one calculation for each of the left and right viewports using the low byte.  Not much help to me without going through the entire game to understand what adding an adjustment to the viewports does.

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

#5465

On Thursday, April 2, 2020 at 10:29:11 PM UTC-7, gid...@sasktel.net wrote:
> Looking at the Stellar7 code has got me even more confused as the view_x_adj+1 isn’t even used after the sign gets stored in it.

Stellar 7 mostly separates the graphics engine from the game engine.  The graphics engine is reasonably generic, supporting 4 viewports and features like constant grid-aligned movement even though it only uses 1 viewport and things only move in the direction they're facing.  (Although it's kind of fun to give obstacles constant movement and watch them zip around.)

In this case, the engine allows you to define the viewport center with 16-bit offsets, so that you can put the center coordinate outside the range represented by a single byte.  The Apple II screen isn't big enough to make this useful.

The functions that use the value (of which there are more in ROCK1 -- it's used to convert the output of the line clip from a signed value to device coordinates) are defined in a very general way and take a 16-bit argument.  The code that calls them needs to convert an 8-bit value to 16 bits, which you do by sign-extending, so e.g. $01 becomes $0001 and $fe becomes $fffe.  The actual implementation of the functions recognizes that the upper 8 bits aren't useful on an Apple II and ignores them.

Anyway.  This is about working with signed integers with different widths.  Sometimes it's worth writing two separate functions for (say) math_thing(8bit arg, 16bit arg) and math_thing(16bit arg, 16bit arg), but other times you just write math_thing(16bit arg, 16bit arg) and convert the 8-bit value to 16 bits before you pass it in.

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

#5467

Thanks for the explanation.

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

#5474

On Thursday, April 2, 2020 at 5:41:38 PM UTC-7, Andy McFadden wrote:
> 
> The point is to convert a signed 8-bit value into a signed 16-bit value.
>   Stellar 7 does some of this in its graphics engine, e.g.:
> 
>                 ldx     #$00              ;assume positive
>                 lda     view_x_adjs,y
>                 bpl     L616D
>                 dex                       ;sign-extend negative
> L616D           sta     VIEW_X_ADJ
>                 stx     VIEW_X_ADJ+1
> 
> (from https://6502disassembly.com/a2-stellar7/ROCK2.html , at $6165)

My technique wins if the low byte is already in-place.  Otherwise, its
 kinda meh ... In your example it would lose by one byte and a cycle
 or two, but would have the possible advantages of constant cycles and
 not disturbing X:

        lda     view_x_adjs,y
        sta     VIEW_X_ADJ
        lda     #$7f
        cmp     VIEW_X_ADJ
        sbc     #$7f
        sta     VIEW_X_ADJ+1

Mike B.

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

#5466

On Thursday, April 2, 2020 at 2:27:47 PM UTC-7, gid...@sasktel.net wrote:
> Is this like an April Fools’s joke?
> 
It wasn't my original intention, but I guess it could be interpreted that way.

> Who are all these 6502 programmers writing new code?
> 
You might be one day late for that one, I think ;-)

Mike B.

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

#5468

Would you happen to have a list of some of those programs where it was used.

I only thought it might be a joke because I have never seen   It used before.  But seeing it used under different circumstances might shed some light for me on programming techniques being used.

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

#5469

The original post is a small and fast version, suitable for inclusion in something like AcheronVM (where it has just been accepted).
It was taken from the Nes Dev site, so presumably Nintendo developers have used it previously.

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

#5471

On Friday, April 3, 2020 at 10:12:13 AM UTC-7, qkumba wrote:
> The original post is a small and fast version, suitable for inclusion in
> something like AcheronVM (where it has just been accepted).
> It was taken from the Nes Dev site, so presumably Nintendo developers
> have used it previously.

I can't find my code at nesdev, and the only response to me so far at
 AcheronVM is one thumbs-up.

Mike B.

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

#5470

On Friday, April 3, 2020 at 9:23:47 AM UTC-7, gid...@sasktel.net wrote:
> Would you happen to have a list of some of those programs where it was used.
> 
> I only thought it might be a joke because I have never seen   It used before.
>  But seeing it used under different circumstances might shed some light for
> me on programming techniques being used.

https://github.com/AcheronVM/acheronvm/issues/5

https://github.com/chitselb/pettil/commit/038da606f386345f75d1906a6cf73b7b434de2bf#diff-83be47cccf4f9f0ae3daa8ce76b4f7ed

Still waiting for a ping-back from the main author of Tali-Forth ...

Mike B.

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

#5472

If it is used in Forth, you timed it perfectly as I have been playing with FigForth and just started disassembling it

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

#5473

On Friday, April 3, 2020 at 2:19:30 PM UTC-7, gid...@sasktel.net wrote:
> If it is used in Forth, you timed it perfectly as I have been playing
> with FigForth and just started disassembling it

http://forum.6502.org/viewtopic.php?p=50867#p50867

Garth has links to some bug-fixes you might want to check out.

Mike B.

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

#5475

Thanks,

After comparing the code it looks like I already had his revised version in assembly form compared to his source form.

I am a little disappointed though he didn’t create or upload any Forth words he might have created.

I have to say though, what a brain rush Forth is.  I can’t believe how there is so little utilities or programs out there for it.  I highly recommend getting into it as a language.

If there is any interest to play with or contribute to the Forth directive I will upload what I have added to it so far.

So far I have created these programming utility words:

Decode - word decoder that decodes all the words that make up the master word.  Like LIST does in applesoft
$List - lists only system words in the dictionary along with their location in memory - removed VLIST
Dlist - only list newly created words and not system words
Varlist - lists only constants and variables and their values
Case - function to select from a numerical list
Instring - selects part of a word within a word
Dump - hex dump modified from its original form to be more user definable
Find - lists technical stuff about a word

On the To-do list:
Editor - allows ability to Read/Write and edit normal text files
Bload - loads a hi-res Or Dbl hi-res graphics screen
Launch - launch a self contained Forth program or system file
Create Hi-res words for plotting and drawing
Selfmake - make a self contained program minus non essential words and minus the compiler

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

#5476

On Sunday, April 5, 2020 at 10:10:13 AM UTC-7, gid...@sasktel.net wrote:
> Thanks,
> 
> After comparing the code it looks like I already had his revised version
> in assembly form compared to his source form.
> 
> I am a little disappointed though he didn’t create or upload any Forth
> words he might have created.
> 
> I have to say though, what a brain rush Forth is.  I can’t believe how
> there is so little utilities or programs out there for it.  I highly
> recommend getting into it as a language.
> 
> If there is any interest to play with or contribute to the Forth directive
> I will upload what I have added to it so far.
> 
> So far I have created these programming utility words:
> 
> Decode - word decoder that decodes all the words that make up the master
> word.  Like LIST does in applesoft
> $List - lists only system words in the dictionary along with their location
> in memory - removed VLIST
> Dlist - only list newly created words and not system words
> Varlist - lists only constants and variables and their values
> Case - function to select from a numerical list
> Instring - selects part of a word within a word
> Dump - hex dump modified from its original form to be more user definable
> Find - lists technical stuff about a word
> 
> On the To-do list:
> Editor - allows ability to Read/Write and edit normal text files
> Bload - loads a hi-res Or Dbl hi-res graphics screen
> Launch - launch a self contained Forth program or system file
> Create Hi-res words for plotting and drawing
> Selfmake - make a self contained program minus non essential words and
> minus the compiler

So, your version has an Apple ][ slant, kind of like Charlie's PETTIL has
 an 8-bit Commodore slant.  I'm certain that you would get courteous and
 intelligent feedback on the Forth sub-forum at 6502.org if you uploaded
 your stuff there, by Forthers who are far more qualified than I am to
 examine your code in detail.

Charlie actually wrote PETTIL from scratch, and made some impressive
 efficiency gains over figForth, or any other 6xxx FORTH I've seen.

Mike B.

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

#5479

On Sunday, April 5, 2020 at 11:43:55 AM UTC-6, Michael Barry wrote:
> On Sunday, April 5, 2020 at 10:10:13 AM UTC-7, gid...@sasktel.net wrote:
> > Thanks,
> > 
> > After comparing the code it looks like I already had his revised version
> > in assembly form compared to his source form.
> > 
> > I am a little disappointed though he didn’t create or upload any Forth
> > words he might have created.
> > 
> > I have to say though, what a brain rush Forth is.  I can’t believe how
> > there is so little utilities or programs out there for it.  I highly
> > recommend getting into it as a language.
> > 
> > If there is any interest to play with or contribute to the Forth directive
> > I will upload what I have added to it so far.
> > 
> > So far I have created these programming utility words:
> > 
> > Decode - word decoder that decodes all the words that make up the master
> > word.  Like LIST does in applesoft
> > $List - lists only system words in the dictionary along with their location
> > in memory - removed VLIST
> > Dlist - only list newly created words and not system words
> > Varlist - lists only constants and variables and their values
> > Case - function to select from a numerical list
> > Instring - selects part of a word within a word
> > Dump - hex dump modified from its original form to be more user definable
> > Find - lists technical stuff about a word
> > 
> > On the To-do list:
> > Editor - allows ability to Read/Write and edit normal text files
> > Bload - loads a hi-res Or Dbl hi-res graphics screen
> > Launch - launch a self contained Forth program or system file
> > Create Hi-res words for plotting and drawing
> > Selfmake - make a self contained program minus non essential words and
> > minus the compiler
> 
> So, your version has an Apple ][ slant, kind of like Charlie's PETTIL has
>  an 8-bit Commodore slant.  I'm certain that you would get courteous and
>  intelligent feedback on the Forth sub-forum at 6502.org if you uploaded
>  your stuff there, by Forthers who are far more qualified than I am to
>  examine your code in detail.
> 
> Charlie actually wrote PETTIL from scratch, and made some impressive
>  efficiency gains over figForth, or any other 6xxx FORTH I've seen.
> 
> Mike B.


I downloaded all the other Forths for the Apple II line as well to examine and implement any code I liked.  Graforth, Qforth, Transforth, MetaCraft Forth ... etc.

I am working off of ProForth, which I believe is Garth's updated forth.  I am more striving for modular design over efficiency, as I would like to be able to create a basic set of words that lets me create self contained applications that only contain the words that are used.  And be able to do something like the way System files are launched and exit back to a system launcher.

Interesting stuff.  I have a lot of reading to do to go over Charlies improvements as well.

Thanks for the links.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web