It is currently Tue Jan 22, 2019 8:20 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Jan 02, 2019 2:07 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7650
Location: Chexbres, VD, Switzerland
I don't indent code, and it barely ever caused any problems. Basically I use vertical spacing when apropriate to make up for the lack of indentation. Also I use local labels such as _loop in order to make things clearer, and sometimes _loop2 for an outer loop, etc.... I use _next when it's the equivalent to a "break" instruction in a higher level language.

One of the point of coding in assembly is not being bound by structures of higher level langusages. For example you can have two loops crossing eachother, a subroutine calling it's own end, or particular cases or stufflike that. This defeats the purpose of indenting completely.

EDIT : Sometimes I label loops according to what they do, such as _wordloop for a loop decoding words in a text, the inner loop decoding letters and the outer loop decoding the entiere line :)


Top
 Profile  
 
PostPosted: Wed Jan 02, 2019 9:41 pm 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2178
Location: Fukuoka, Japan
@pwnskar

For the lack of use of indentation, I guess it must be because I started to write assembler this way and saw code formatted this way ~25 years ago. It is possible that maybe the assembler was forcing it but I cannot tell since I was barely copying how other people were doing it in those days and my knowledge of programming was still in its infancy ^^;;;


Top
 Profile  
 
PostPosted: Wed Jan 02, 2019 11:31 pm 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 644
oh to be clear

ldx #8
L1
lda thing,x
sta place,x
dex
bne L1
..

Is the standard and only way it was done back in the day. Its all well and good to have modern sensibilities but when you are coding on a C64 with no TAB key, 40 columns and every character uses precious precious RAM and CPU cycles. Or a 5K 22column VIC20 or a 4K PET or APPLE ][. You keep label as short as possible <6 is the "standard"(if you are using a C64, on a 4/5K machine there is no room for labels.) Using Line editors while giving you more cpu power, makes typing painful. And when you have a 4~30mins Assemble you do everything you can to make it faster. Whitespace slows you down.

So even when we got to 80 column screens we used it as 2 40 col screens as there was no mouse, F12, PgUp PGDown, Bookmarks, autocomplete, other handy documents etc so being able to keep 1 half of the screen on variable names was very handy.

See also C
K&R style is
Code:
void myFunction(bool var) {
    some code here
}
which is nice as it cuts down the number of lines and the number of lines you need to edit and the number of lines the code need to parse etc.
These days Stroustrup style is more popular
Code:
void myFunction(bool var)
{
    some code here
}


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 12:45 am 
Offline

Joined: Wed Nov 30, 2016 4:45 pm
Posts: 123
Location: Southern California
pwnskar wrote:
I sort of follow what I'm used to from other languages just because it makes things easier for me to read and wrap my head around. I'm not super consistent with it but for me that's not really the point. I just want to be able to read and understand what I'm doing with the code, so with that I usually do a lot of comments and little "TODO" notes.

I'll follow Banshaku's example and show you my take on the same task. :)

Code:
BufferOffsetBackgroundPalette:

   ; a = how much to subtract from currently loaded palette.
   
   ; TODO: if the palette pointers have not been set yet, do something to handle that.
   
   ldx palette_bkg_ptr_lo
   ldy palette_bkg_ptr_hi
   
   stx curr_pointer_lo
   sty curr_pointer_hi
   
   ldx #15
   
   jmp BufferOffsetPalette
   
BufferOffsetSpritePalette:
   
   ; a = how much to subtract from currently loaded palette.
   
   ldx palette_sprites_ptr_lo
   ldy palette_sprites_ptr_hi
   
   stx curr_pointer_lo
   sty curr_pointer_hi
   
   ldx #31
   
BufferOffsetPalette:
   
   ; x = palette_buffer end index
   
   pha   ; how much to subtract
   
   lda nmi_flags
   and #NMI_UPDATE_PALETTE_CLEAR
   sta nmi_flags
   
   ldy #15
   @offsetloop:
      
      pla
      pha      ; push this for next loop iteration
      clc
      adc (curr_pointer_lo), y   ; offset palette value with a
      pha                     ; push this so we can use a for some logic
      
      ; first, lets knock down all $xE and $xF to $xD
      and #%00001111
      cmp #$0e
      bcc @no_xE
         ; we've determined that the value must be $xE or $xF
         
         ; knock it down to $xD
         pla            ; retrieve offset palette value
         and #%11110000
         ora #%00001101
         jmp @xEset
      
      @no_xE:
         pla            ; retrieve offset palette value
      @xEset:
      
      
      ; TODO: determine if the offset was positive or negative.
      ; we could do that by temporarily storing a in the buffer and digging out the initial offset by pla
      sta palette_buffer, x
      
      pla      ; retrieve original offset value
      pha      ; and push it again for next loop itteration.
      bpl @offsetispositive
         
      @offsetisnegative:
      
         lda palette_buffer, x
         cmp #$20
         bne @not20
            lda #$10
            sta palette_buffer, x
            ;jmp @offset_adjusted_by_direction
         @not20:
         
         jmp @offset_adjusted_by_direction
         
      @offsetispositive:
      
         lda palette_buffer, x
         cmp #$1d
         bne @not1d
            lda #$2d
            sta palette_buffer, x
            jmp @offset_adjusted_by_direction
         @not1d:
         cmp #$2d
         bne @not2d
            lda #$00
            sta palette_buffer, x
            ;jmp @offset_adjusted_by_direction
         @not2d:
         
         
      @offset_adjusted_by_direction:
      
      lda palette_buffer, x
      cmp #$3d+1            ; so now we check if any value goes above 3d (out of range) and cap it to either 30 or 0d
      bcc @nocap            ; is the value above 127?
         cmp #0
         bpl @nocap1
            ; if the offset was negative, this is our stop
            lda #$0d
            jmp @nocap
         @nocap1
            ; this is where we end up if the offset was positive
            lda #$30
      @nocap
      
      sta palette_buffer, x
      
      dex
      dey
      cpy #$ff
      bne @offsetloop
   
   pla      ; clean stack from original a value
   
   ; TODO: patch all sprite opacity buffers with that of the background palette buffer
   lda palette_buffer
   sta palette_buffer+16   ; seems just patching the first entry of the sprite palette buffer is enough..
   
   lda nmi_flags
   ora #NMI_UPDATE_PALETTE
   sta nmi_flags
   
   rts

I'm surprised so many people seem to not do indentation! :) For me that simply wouldn't work. My mind needs some visual aide even to just help my eye find it's way back to the right spot on the screen when going back and forth between all my source files.

That's excellent! Probably the best that could be done without program-structure macros. With them, I might modify it to the following. Note that no labels are needed except the two I left at and near the top as entry points. Hopefully I didn't make any mistakes, as I was quickly converting the form without focusing much on the bigger picture of what the program is doing. The section of triple-nested IF's could stand some more comments.

Code:
BufferOffsetSpritePalette:       ; a = how much to subtract from currently loaded palette.

   LDX  palette_sprites_ptr_lo
   LDY  palette_sprites_ptr_hi
   
   STX  curr_pointer_lo
   STY  curr_pointer_hi
   
   LDX  #31
   
BufferOffsetPalette:             ; x = palette_buffer end index

   PHA                           ; how much to subtract
   
   LDA  nmi_flags
   AND  #NMI_UPDATE_PALETTE_CLEAR
   STA  nmi_flags
   
   FOR_Y  15, UP_TO, $FF         ; (offset loop)
      PLA
      PHA                        ; Copy TOS into A.
      CLC
      ADC  (curr_pointer_lo), Y  ; Offset palette value with A.

      PHA                        ; Push this so we can use A for some logic.
      AND  #%00001111            ; Knock down all $xE and $xF to $xD.
      CMP  #$0E
      IF_CARRY_SET               ; We've determined that the value must be $xE or $xF; so
         PLA                     ; knock it down to $xD.  First retrieve offset palette value.
         AND  #%11110000
         ORA  #%00001101
      ELSE_
         PLA                     ; Retrieve offset palette value.
      END_IF
     
     
                                 ; TODO: determine if the offset was positive or negative.  We could do that by
                                 ; temporarily storing A in the buffer and digging out the initial offset by PLA
      STA  palette_buffer, X
     
      PLA                               ; Copy offset from TOS into A.
      PHA
      IF_NEG                            ; If it's negative:
         LDA  palette_buffer, X
         CMP  #$20
         IF_EQ
            LDA  #$10
            STA  palette_buffer, X
         END_IF
      ELSE_                             ; But if it's positive:
         LDA  palette_buffer, X
         CMP  #$1d
         IF_EQ
            LDA  #$2d
            STA  palette_buffer, X
         ELSE_
            CMP  #$2d
            IF_EQ
               LDA  #$00
               STA  palette_buffer, X
            END_IF
         END_IF
      END_IF         
     
      LDA  palette_buffer, X     ; Continue now for offset adjusted by direction:
      CMP  #$3d+1                ; Now we check if any value goes >3d (out of range) and cap it to either 30 or 0d.
      IF_GE                      ; Is the value above 127?  [Shouldn't that say "above 61"?]
         CMP  #0
         IF_LT
            LDA  #$0d            ; If the offset was negative, this is our stop.
         ELSE_
            LDA  #$30            ; This is where we end up if the offset was positive.
         END_IF
      END_IF
     
      STA  palette_buffer, X
     
      DEX
   NEXT_Y                        ; (back to top of offset loop)
   
   PLA                           ; clean stack from original a value
                                 ; TODO: patch all sprite opacity buffers w/ that of the background palette buffer.
   LDA  palette_buffer
   STA  palette_buffer+16        ; Seems just patching the first entry of the sprite palette buffer is enough.
   
   LDA  nmi_flags
   ORA  #NMI_UPDATE_PALETTE
   STA  nmi_flags
   
   RTS
 ;-------------

To answer Bregalad's objection, you can still use labels and explicit branches and jumps if desired; but I try to minimize them. A main reason for using assembly language is performance; and if I didn't make any mistakes in my quick conversion above, the assembled code will be identical to the earlier version.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 8:19 am 
Online

Joined: Tue Oct 16, 2018 5:46 am
Posts: 47
Garth wrote:
Code:
      IF_GE                      ; Is the value above 127?  [Shouldn't that say "above 61"?]

I think my reasoning was that at that place in the code we don't know which direction we've offset in. It could probably be reworked a bit, since I'm checking for direction twice, but I've left it that way for now since it works... :P

I've yet to use macros, but I probably will once I feel more comfortable with regular assembly. I can definitely see how they would make life a little easier. Thanks for the example!


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 11:43 am 
Offline

Joined: Wed Nov 30, 2016 4:45 pm
Posts: 123
Location: Southern California
pwnskar wrote:
Garth wrote:
Code:
      IF_GE                      ; Is the value above 127?  [Shouldn't that say "above 61"?]

I think my reasoning was that at that place in the code we don't know which direction we've offset in. It could probably be reworked a bit, since I'm checking for direction twice, but I've left it that way for now since it works... :P

This line was immediately following a comparison to $3D+1 which is 62; so branching on the carry flag splits 61, 60, 59,... from 62, 63, 64...

Quote:
I've yet to use macros, but I probably will once I feel more comfortable with regular assembly. I can definitely see how they would make life a little easier. Thanks for the example!

I used macros for three decades before I realized there was a way to use them for nestable program structures. Next I need to figure out a way to use them to automatically create and destroy local variables.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 2:06 pm 
Offline

Joined: Tue May 26, 2009 5:39 am
Posts: 20
Oziphantom wrote:
See also C
K&R style is
Code:
void myFunction(bool var) {
    some code here
}

No, its the Java-style.

Oziphantom wrote:
These days Stroustrup style is more popular
Code:
void myFunction(bool var)
{
    some code here
}

Or better known as K&R style :)


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 2:13 pm 
Online
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 546
Location: Central Illinois, USA
cyc wrote:
Or better known as K&R style :)


K&R is an awful mix, where braces for functions are on their own lines, but braces in control blocks are on the same line
https://en.wikipedia.org/wiki/Indentation_style#K&R_style

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group