20 Basic Practices in Assembly Language Programming

[RuiLoureiro]

With a quick scan, his reference material looks OK and much of it is just good programming practice but nothing beats the Intel manuals once you can get your head around them. I am always wary of any form of "politically correct" notions of how you write code and particularly with assembler code, architectural freedom is one of its greatest advantages. Others have written optimisation techniques, Agner Fog did very influential work as well as one of the Intel manuals but nothing beats the clock, design it, time it and keep going until the numbers don't get any lower. 

After that, then try it on different processor versions and learn the joys of average performance across a variety of different processors.  :P

XCHG was slow on a single core PIV, it never got any better on multicore hardware. Try and forget old DOS style instructions, they were super heros on a 286, anything committed to processor microcode is there for backwards compatibility reasons.

YES ! Very well ! :t
:icon14:
EDIT: i like this sentence: «visual garbage generator»!  :icon_cool:

[RuiLoureiro]

20 Basic Practices in Assembly Language Programming, CodeProject, by Zuoliu Ding.

The article is good for novices. But there are other sources, too.

... but nothing beats the clock, design it, time it and keep going until the numbers don't get any lower. 

That's the right approach.

Gunther

Hi Gunther,
                  How are you ?
Nice to see you here :t

[RuiLoureiro]

Hi all
      I want to add this:
      If we write a procedure that uses a local stack buffer of length N and it may be used
      to copy from/to another using movdqa/movdqu instructions and registers xmm, it
      is fast if the starting address is aligned by 16. I don't know if all this type of
      buffers are created aligned by 16 or not and i never tested it (i align it by 16)
      What do you have to say ?
      More, it seems that a procedure that uses local variables, when we have the carry clear
      and call that procedure and it starts by pushfd and exits with popfd, the next state of
      carry flag may be carry set. I don´t know why. 

For instance

ProcA                  proc           pStrBuf:DWORD, pSubType:DWORD

                            LOCAL       BufferB[TOTALofSTACKBUFFER1024]:BYTE
                            LOCAL       BufferC[TOTALofSTACKBUFFER512]:BYTE
                            LOCAL       BufferD[TOTALofSTACKBUFFER512]:BYTE

                            push        ebx
                            push        esi
                            push        edi
            ;
            ; something
            ;
                            pop          edi
                            pop          esi
                            pop          ebx
                            ret
ProcA                   endp

[nidud]

deleted

[Gunther]

Hi Gunther,
                  How are you ?
Nice to see you here :t

All things considered, I'm doing just fine. And how are you?

      More, it seems that a procedure that uses local variables, when we have the carry clear
      and call that procedure and it starts by pushfd and exits with popfd, the next state of
      carry flag may be carry set. I don´t know why. 

I agree with nidud: it's the prologue.

Gunther

[RuiLoureiro]

      More, it seems that a procedure that uses local variables, when we have the carry clear
      and call that procedure and it starts by pushfd and exits with popfd, the next state of
      carry flag may be carry set. I don´t know why. 

I will assume it's the prologue code:

Code Select Expand


local   x
*   push   ebp
*   mov   ebp,esp
*   sub   esp,4   ; <-- changes the flags
   pushfd


Hi nidud,
          I think so. Thanks  :t
          Now, all my TestProcs that i put after «_exit» doesnt use
          any local variables or it uses global variables.
         
Example: (note:all Test Procs start with pushfd and pushad
                 and exit with popad and popfd and ret)

ProcA                proc          pStrBuf:DWORD, pSubType:DWORD
                       LOCAL       BufferB[TOTALofSTACKBUFFER1024]:BYTE
                       LOCAL       BufferC[TOTALofSTACKBUFFER512]:BYTE
                       ...
                       push        ebx
                       push        esi
                       push        edi
                       ;-------------------------------------------
                       ;   Align by 16 BufferB and put the pointer
                       ;     into edi and ebx for BufferC.
                       ;-------------------------------------------
                       ALIGNLOCALPOINTERedi  BufferB, LENofSTACKBUFFER1024
                       ALIGNLOCALPOINTERebx  BufferC, LENofSTACKBUFFER512                       
                       ...
                       mov             esi, pStrBuf
                       ...
       ;
       ; something
       ;       
           _isdone:    clc          <<<<<<<--------------------
                       ;----------------------------------------
                       ; If it exits with clc, it did the task
                       ; If it exits with stc, there is an error
                       ;----------------------------------------
             _exit:   
                       ;----------------------------------------
                       ; This test proc starts showing the carry flag:
                       ; If clear -> we get: the carry is CLEAR
                       ;    NOT   ->       : the carry is SET
                       ;----------------------------------------
                       invoke       SomeTestProcX, A, B...
                       or
                       call         SomeTestProcX
                       ;------------------------------------------
                       ; If SomeTestProcX uses local variables
                       ; we get: the carry is SET and we know
                       ; that ProcA exits in the label «_isdone».
                       ;------------------------------------------
                       pop          edi
                       pop          esi
                       pop          ebx
                       ret
      _erro273:    ...
                       stc
                       jc           short _exit                       
ProcA                endp                           

[RuiLoureiro]

Hi Gunther,
                  How are you ?
Nice to see you here :t

All things considered, I'm doing just fine. And how are you?

      More, it seems that a procedure that uses local variables, when we have the carry clear
      and call that procedure and it starts by pushfd and exits with popfd, the next state of
      carry flag may be carry set. I don´t know why. 

I agree with nidud: it's the prologue.

Gunther

Hello Gunther,
   i'm fine but older. It's a nature problem !
There is no solution, even using assembly laguage, Gunther !
See you and Good Luck. :t
:icon14:
Rui

[GuruSR]

20 Basic Practices in Assembly Language Programming, CodeProject, by Zuoliu Ding.

The article is good for novices. But there are other sources, too.

... but nothing beats the clock, design it, time it and keep going until the numbers don't get any lower. 

That's the right approach.

I actually got into a debate on one site (related to a game) with a C programmer who stated that nobody clock counts, ever.

I've written an Jump Man Jr. clone on a Vic-20 (hell if I didn't count cycles) that did animated "sprite like" movement with collision detection on the pixel level (and I used a raw memory editor that let me write code directly in ram, damn sure I counted).  Wrote an addition of the Vic-20 and a robotic arm, so it would be 1/10th of a degree accurate in all movements with it (infrared sensors), that one I used an "IDE" of sorts and wrote that extension, wrote a "to be rom" for a DJ control for lighting, had to be able to read the sound and react to it with light patterns, that I counted code, because the rom was only so big (2k if I recall) and he wanted patterns to be programmable.

Anyone who isn't counting the clock for performance is either not worried about it, or another lazy C programmer...  Must be working for Microsoft.  <VENT>"Hey Microsoft, fix the Windows 3.1 bug in Windows 10 will you?!  I hate having to deal with the print spool causing all the printers to vanish, like FIX that bug already."</VENT>

One of these years, I'll get around to using macros in the IDE, maybe...  Too old school, do it all myself, at least there's an IDE now, not like raw editing memory.

GuruSR.

[Gunther]

Hi GuruSR,

I actually got into a debate on one site (related to a game) with a C programmer who stated that nobody clock counts, ever.

This buddy has no idea. That's for sure.

I've written an Jump Man Jr. clone on a Vic-20 (hell if I didn't count cycles) that did animated "sprite like" movement with collision detection on the pixel level (and I used a raw memory editor that let me write code directly in ram, damn sure I counted).  Wrote an addition of the Vic-20 and a robotic arm, so it would be 1/10th of a degree accurate in all movements with it (infrared sensors), that one I used an "IDE" of sorts and wrote that extension, wrote a "to be rom" for a DJ control for lighting, had to be able to read the sound and react to it with light patterns, that I counted code, because the rom was only so big (2k if I recall) and he wanted patterns to be programmable.

That sounds impressive. Canada must be a good area for assembly language programmers.  8)

Gunther

[GuruSR]

This buddy has no idea. That's for sure.

Long before C programming was even a thing, I was writing code on punch cards (and no, never crashed that one, trust me, you knew it when that happened, shook the floor), then next wrote a logic circuit on paper and created the actual live circuit in electronics.  So when someone tells me nobody counts cycles, I laugh as I know that hand held game device game programmers have no choice, because his answer was to throw more horse power (faster CPU) at it.     And my comment to him was (since it was an XBox360/PC game), that it's a nice idea for the PC, but what about those people with the XBox 360 version, both were written using the same base code (as was a good means of reducing production costs).  He still said that they didn't count cycles for the game and it just "worked fine" as it was...  I was so tempted to ask him to write a mini game that couldn't be any larger than 8k in size (I didn't, because I know PrintF is a lot larger than that).

That sounds impressive. Canada must be a good area for assembly language programmers.  8)

Thanks, yes, my youth was mostly coding, pretty much, got a recognition for writing an assembler 'simulation' program so people learning assembler in the years following would use my 'simulation' to watch how the process worked.  That was basically what I did in that course since I finished the course in a week (helped learning assembler over the summer with my own Vic-20, but the machines at the school were Commodore Pet's, wow, nostalgia).  Got asked why I was able to finish the projects so fast, well, the year prior, I was the only guy in a typing course.  I figured, I need to learn to type to program faster, so I took the course and well, now I'm roughly 60-70wpm.  The following year, I heard a few of the guys joined a course just to get better too, some of the girls in that course were "upset at me for suggesting it"...  Oh no, Drama at School, film at 11!

GuruSR.