flat assembler
Message board for the users of flat assembler.

Index > Macroinstructions > fprint "%d = %b \n",[x],[y]

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
Hi people. just wondering what could be the best macro setup to produce something like the above?

My macro can interpret only [x] but not [y]. It prints both decimal (%d) and binary[%b] for x only when it should print [y] in binary.

I used this header

Code:
macro fprint [a,b]
{
     ...
     cmp word[si],'%d' ;si points to string, which is a
           je .int
     ...
.int: prtint [b] ;calls another working macro
     ...
.bin: prtbin [b]
     ...
}    


Thanks in advance. P/s I cant post my complete macro coz I am on my smartphone.
Post 21 Feb 2014, 15:12
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
fasmnewbie,

macro fprint fmt*, [arg*] perhaps? Because with your declaration each implicit forward iteration gets pair of arguments, i.e. for second one a==[y], b==«» (empty).
Post 21 Feb 2014, 18:29
View user's profile Send private message Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
baldr wrote:
fasmnewbie,

macro fprint fmt*, [arg*] perhaps? Because with your declaration each implicit forward iteration gets pair of arguments, i.e. for second one a==[y], b==«» (empty).


Hi baldr.

This is the structure of the said macro, changing the header as you suggested

Code:
macro fprt fmt*,[args*]
{
        local .b,.done,.loop,.line,.char
        local .int,.oct,.hex,.bin,.sig,.gg
        xor si,si
        mov ah,0eh
forward
.loop:  cmp byte[cs:.b+si],0
            je .done
        cmp word[cs:.b+si],'\n'
            je .line
        cmp word[cs:.b+si],'%d'
            je .sig
        ;Other compares/bases omitted
        ;Keeps printing local string
        mov al,byte[cs:.b+si]
        int 10h
        inc si
        jmp .loop
.sig:   prtint args,-s,-line       ;other macro
        jmp .gg
.line:  line                       ;other macro
.gg:    add si,2
        jmp .loop
        .b db fmt,0                ;local string
.done:
}

fprt "Your numbers are %d and %d\n",[x],40

exitp   ;pause and quit
x dw 30    


The output is:
Code:
Your numbers are 30 and 30
    


If I commented the forward thing, it prints twice like this:
Code:
Your numbers are 30 and 30
Your numbers are 40 and 40
    


Do I have to restructure the entire macro or just the part that needs to be forwarded. Completely clueless on this forward thing. I tried putting common (everywhere!) but to no avail.

Thanks for your advice.
Post 23 Feb 2014, 08:37
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
fasmnewbie
One of the worst common sins of newbies is not being able to correctly decide, whether a macro fits better or a function. What your macro does is taking each argument and putting into code a whole function, that processes the whole format string for every single argument. Disregarding the correctness of the resulting code you also create two, three, ten ... copies of the same code including the same number of copies of the format string.

As a side note, macros with variable argument count have implicit forward . This means that your macro in fact has two forward blocks. Thus you first put clearing si and initializing ah multiple times in the code successively, and then you put multiple blocks of the remaining code. This way si is not reset before processing the second block and that's why you get your output only once with the uncommented forward.

To sum up. Stop writing macros for tasks solvable with procedures/functions. Blowing up the code size by successively putting identical code pieces is of no interest. I'm disappointed, no one ever pointed this out in this topic.

_________________
Faith is a superposition of knowledge and fallacy
Post 23 Feb 2014, 13:39
View user's profile Send private message Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
l_inc wrote:
fasmnewbie
One of the worst common sins of newbies is not being able to correctly decide, whether a macro fits better or a function. What your macro does is taking each argument and putting into code a whole function, that processes the whole format string for every single argument. Disregarding the correctness of the resulting code you also create two, three, ten ... copies of the same code including the same number of copies of the format string.

As a side note, macros with variable argument count have implicit forward . This means that your macro in fact has two forward blocks. Thus you first put clearing si and initializing ah multiple times in the code successively, and then you put multiple blocks of the remaining code. This way si is not reset before processing the second block and that's why you get your output only once with the uncommented forward.

To sum up. Stop writing macros for tasks solvable with procedures/functions. Blowing up the code size by successively putting identical code pieces is of no interest. I'm disappointed, no one ever pointed this out in this topic.



Hi I_inc. I am fully aware of those overhead when using macros instead of procs. I have no objections of what you are saying. But I have my personal view on this, especially coming from on-off hobbyist like me.

1. I see macros as an "idea book" that I can conveniently develop, test, maintain and "forget", all in a single file, at any rate, at any time. I don't have that convenience when using procedures/functions

2. I see macros as a convenient tool to distribute complete "units" of code. AFAIK, macros are highly distributable and redistributable as a "unit" than a proc.

3. Since the "idea" is there wrapped in a macro, it takes just a little effort to transform them into a proc. For example, from my bconv macro, I can easily come up with this proc, which is highly identical with the macro version;

Code:
;BASE CONVERTER
;Base min=2,max=36
;Expects: Push The base (imm)
;       : Push The value - imm16,[dw]
;Returns: Display
.BCONV:
        push bp
        mov bp,sp
        mov ax,[bp+4];the value
        mov cx,[bp+6];the base
        xor si,si
        xor dx,dx
.st:    div cx
        push dx
        inc si
        test ax,ax
            jz .pr
        xor dx,dx
        jmp .st
.pr:    dec si
        pop ax
        add al,30h
        cmp al,39h
            jbe .o
        add al,7
.o:     test si,si
            jz .d
        mov ah,0eh
        int 10h
        jmp .pr
.d:     pop bp
ret    


4. I did mention in that topic that the macros are not to be used for large programs. I meant it for newbies like me to use it to test, probe or validate their codes, visually. Just for short tasks. A macro that is called once, is just as good as a procedure in terms of code size, IMHO.

But I have to admit, sometime I got carried away out of excitement exploring/finding new things. You can't blame me for this. You were there too helping me with my first macros. You and baldr are my gurus. I won't forget that. hahaha Very Happy
Post 23 Feb 2014, 14:57
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
fasmnewbie
Quote:
But I have my personal view on this

Then let me, please, try to understand your view.

1.
Quote:
I don't have that convenience when using procedures/functions

I fail to see any even tiny advantage of macros with respect to the convenience of conserving and reusing ideas implementable as procedures. Moreover, if your idea is let's say to output a decimal value onto the screen, then a procedure would just contain assembly code being the essence of the actual conversion and output process. If you write a macro for that, then the assembly code is completely mixed up together with assembly directives, which makes it much less readable.

2.
Quote:
AFAIK, macros are highly distributable and redistributable as a "unit" than a proc

How is that? How is a macro a more complete or more distributable unit of code than a procedure? On the contrary, if you try to distribute a macro library instead of a procedure library for routines like printing a string, no single sane programmer is gonna use it for the two mentioned reasons: worse readability and code replication.

The code replication is by the way an enemy of reuse, because you create multiple pieces of code solving the same task instead of using the same code. Recursion, which is a classical example (a procedure reuses itself while breaking its larger task into subtasks) for reusability, is not possible with your approach.

3.
Quote:
Since the "idea" is there wrapped in a macro, it takes just a little effort to transform them into a proc

Again, not for recursive procedures. Besides, procedures are what you need to directly use your "idea book" without any additional effort. Why do you want to complicate the use by forcing yourself or anyone else to put this even if little but still effort?

I didn't see your bconv macro, but I assume it will in contrast to the procedure not correctly work, if you try to pass base in ax and value in cx.

4.
Quote:
A macro that is called once, is just as good as a procedure in terms of code size, IMHO.

In many cases it's even better. But as soon as you invoke it once more it becomes much worse right away.

Quote:
I did mention in that topic that the macros are not to be used for large programs. I meant it for newbies like me to use it to test, probe or validate their codes

That only partially justifies macros. First of all, I personally would strongly discourage anyone from using macros instead of procedures in any programs no matter large or small. Especially newbies, who should from the very beginning avoid bad practices.

What is good about those macros is that you could learn for yourself the macrolanguage and the approaches of solving the corresponding tasks.

P.S. Well. Having said all that, their might be a smart combination of the approaches into "macroprocedures". By that I mean that every procedure from your "idea book" could be wrapped into a basic macro of kind define_fprt that puts the corresponding procedure definition at that specific location. However the only advantage of that approach is the ability to control the actual location of the code.

P.P.S.
Quote:
You were there too helping me with my first macros. You and baldr are my gurus

Thank you. That's nice to know. But for the sake of integrity I would like to humbly note, that I'm l_inc, not "I_inc" Wink . To be honest, baldr was my image of macroperfection, when I was learning fasm macrolanguage. I didn't ask him questions, but I learned a whole lot from his samples of macros.

_________________
Faith is a superposition of knowledge and fallacy
Post 23 Feb 2014, 17:50
View user's profile Send private message Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
Then let me, please, try to understand your view....

OK... Very Happy

Lets define learning convenience.

Code:
org 100h
macro tester 
{
    mov ax,bl
}

exit    


vs

Code:
org 100h

tester:
   mov ax,bl
ret

exit
    


Now you tell me which one would produce an error without even start calling each of them? You see how permissive and useful a macro is to error-prone newbies? You can't get this permissive and on/off convenience with a proc. Not to mention the size of the code already committed by the proc. ;D

You can include 100's of erronuous macros without even committing a single byte/error to the main program. These errornous macros can be your "idea" or something that doesnt have to wait for completion. Just put the idea there in one single place/file, include it, while you are still safe playing with the main program with other completed macros. That's convenience #2 which you can't get with procs. A single error in any of your procs and the entire program stalls, even the correct proc will be useless.

That's scary by any newbies standards

Convenience #3
I can go on with this, but later I realized that we have a different views on this issue. You see it in terms of performance (size,speed,good practice) while I see it from a cluless newbie POV just trying to get started.
Post 23 Feb 2014, 19:32
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
Quote:
Again, not for recursive procedures. Besides, procedures are what you need to directly use your "idea book" without any additional effort. Why do you want to complicate the use by forcing yourself or anyone else to put this even if little but still effort?

I didn't see your bconv macro, but I assume it will in contrast to the procedure not correctly work, if you try to pass base in ax and value in cx.


I don't see any newbies that would be that excited about assembly's recursive procedures at their earliest learning curve. You are setting the standards too high guru Very Happy

The most problem I see from newbies including myself is to see results immediately and in less messy way. Most newbies are playing with the guessing games most of the time and that's really time consuming. So instead of playing with guessing games of what's really happening deep down, I offer newbies a macro that helps them see it visually.

Code:
org100h
include 'lib16.inc'

std
flags --> learn setting the direction flags VISUALLY
cld
line 
flags --> See the flags changes VISUALLY.
exitp
    


I don't force anyone to use any of my macros. I just offer them help to get started because I was once there and that's PITA.

And I don't see any problem with bconv both in macro form or in proc style. Or may be I did miss something?

Btw the fprint macro is just my attempt to simulate a C's printf statement. I coded it just for fun and to extend my knowledge. Thanks for the help (but I still don't get what you are suggesting with that forward thingy). hehe Very Happy
Post 23 Feb 2014, 20:14
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
fasmnewbie
OK. That's a valid explanation in fact. Like you could play and mess around a bit with some parts of code and arbitrarily engage other parts and try to see how things work. What you should remember is however, that you firstly won't be able to create a reusable code library of those pieces of code, and secondly you'll start confront tricky problems using macros much sooner than using procedures once the things get just a bit more complicated. That's what actually already happens with the fprt macro: you need to iterate over the arguments in a normal x86-code driven loop (in synch with the iteration over the format string) instead of trying to forward-iterate over the variadic macro arguments.

Quote:
Now you tell me which one would produce an error without even start calling each of them?

That's unless you involve procedure definition with the proc macro like this:
Code:
proc tester
   mov ax,bl 
ret
endp    

Besides my guess is that every newbie has an intuitive notion of control flow, which should render impossible such a simple problem and make the newbie place all procedure definitions beyond primary execution path (like after the exit). Misunderstandings of the fasm macro conceptions result in much more complicated problems. Just consider a situation when you accidentally create two macros with the same name: with a procedure redefinition you'll get a compiler error, but with a macro redefinition you'll get a mess.

Quote:
That's convenience #2 which you can't get with procs.

The proc macro comes again to the rescue. For the 16-bit procedures one just needs the 16-bit version of the macro (e.g. from here).

Quote:
A single error in any of your procs and the entire program stalls, even the correct proc will be useless.

I miss the point here. Unless a procedure is misplaced it does not contribute to the faultiness of code until it's explicitly invoked. Same as with macros.

Quote:
I can go on with this, but later I realized that we have a different views on this issue

My point is that the "macros-no-procedures-style" is inferior from any perspective.

Quote:
And I don't see any problem with bconv both in macro form or in proc style. Or may be I did miss something?

Maybe. I see your bconv is implemented like this:
Code:
macro bconv a*,to*
{
        local .prt,.start,.done,.ok
        pusha
        if ~ to eqtype 0 | to>36 | to<2
           jmp .done
        end if
        mov ax,a
        mov bx,to
        xor si,si
......................    

You can't invoke it like bconv bx,ax, because you'll get no output. That wouldn't be a problem with a procedure. Remove that if-condition and you'll get an expansion like this:
Code:
push a
mov ax,bx
mov bx,ax ;<-- oops, [i]ax[/i] is messed up
xor si,si    


Quote:
I still don't get what you are suggesting with that forward thingy

My general suggestion is to start using the proc macro instead of making macros out of procedures. If you still prefer to create a macro, then the best you can do is to simulate a variadic procedure by pushing the arguments onto the stack in a reverse-block and then pop them in a loop located in a common block like this:
Code:
macro fprt fmt*,[arg*] 
{ 
reverse push arg
common
        xor si,si 
 .loop:
        mov ah,0eh 
......................
        jmp .loop
.sig:
        pop ax
        prtint ax,-s,-line
......................    

_________________
Faith is a superposition of knowledge and fallacy
Post 23 Feb 2014, 21:01
View user's profile Send private message Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
Quote:

My point is that the "macros-no-procedures-style" is inferior from any perspective.


It is because you are missing the point of my macro libs. I blame myself in part for not making it clear to you as to the purpose of the macros I wrote.

Lets go back to the .BCONV proc earlier. This time we test it as working code;

Code:
org 100h

jmp start
        x dw 70  ;46h
start:
        push 16  ;Display base 16 of x
        push [x]
        call .BCONV
        call .EXITP

;BASE CONVERTER
;Base min=2,max=36
;Expects: Push The base (imm)
;       : Push The value - imm16,[dw]
;Returns: Display
.BCONV:
        push bp
        mov bp,sp
        mov ax,[bp+4];the value
        mov cx,[bp+6];the base
        xor si,si
        xor dx,dx
.st:    div cx
        push dx
        inc si
        test ax,ax
            jz .pr
        xor dx,dx
        jmp .st
.pr:    dec si
        pop ax
        add al,30h
        cmp al,39h
            jbe .o
        add al,7
.o:     mov ah,0eh
        int 10h
        test si,si
            jz .d
        jmp .pr
.d:     pop bp
        ret

;============
.EXITP:
        mov ah,0
        int 16h
        mov ah,4ch
        int 21h
ret    


Assuming a newbie wants to confirm whether he/she really did push the correct value (which is x, in ax) onto the stack frame and didnt mix it up with the base. Instead of guessing, he can call various macros from the lib16 to visually confirm that the correct value has been loaded into AX register. He can choose many options to confirm this

1. Calling the prtr macro to print the value contained in the AX register
2. Calling the prti macro to print the value of AX in decimal
3. Ironically, he can call the bconv macro with base 10 to confirm that AX is in fact is correctly loaded with 70.

All he needs to is to do is include the lib16

Code:
org 100h
include 'lib16.inc'
...
...
        mov ax,[bp+4];the value
        prtr ax,-d        ; confirm it VISUALLY
        mov cx,[bp+6];the base
...
    


Once he can visually confirm the correct value in AX, he can easily comment out or delete the macro calls happily and proceed with the code without any extra overhead incurred.

This is the real purpose of this macro file. To test, to probe or to verify visually. Just imagine how fast a newbie can learn with a helper macro like this (not necessarily mine) instead in getting involved in time-consuming guessing game.

Ironically, he can even call .BCONV's cousin in the macro file to confirm this;

Code:
org 100h
include 'lib16.inc'
...
...
        mov ax,[bp+4];the value
        bconv ax,10         ; confirm it contains 70
        mov cx,[bp+6];the base
...
    


I hope this can make it clear to you to the real purpose of the helper macro I wrote and the effort I am making here.
Post 24 Feb 2014, 12:34
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
That's a good suggestion on the bconv macro. But i intend to leave to to part to take only immediates because I intend to use it internally as a quick probing macro. There are other macros that do conversions with switches.

convert
conv
and any of the prti/o/h/b macros

Quote:
My general suggestion is to start using the proc macro instead of making macros out of procedures. If you still prefer to create a macro, then the best you can do is to simulate a variadic procedure by pushing the arguments onto the stack in a reverse-block and then pop them in a loop located in a common block like this:
Code:
macro fprt fmt*,[arg*] 
{ 
reverse push arg
common
        xor si,si 
 .loop:
        mov ah,0eh 
......................
        jmp .loop
.sig:
        pop ax
        prtint ax,-s,-line
......................    


That's why you are my guru. You never cease to post quality codes and solutions on this board although you are a bit pushy when you argue with Privalov. HAHAHA Very Happy
Post 24 Feb 2014, 12:55
View user's profile Send private message Visit poster's website Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1409
Location: Toronto, Canada
AsmGuru62
What about the debugger?
I think the debugger should be used to confirm values in registers and memory.
Post 24 Feb 2014, 16:10
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7724
Location: Kraków, Poland
Tomasz Grysztar
fasmnewbie wrote:
You never cease to post quality codes and solutions on this board although you are a bit pushy when you argue with Privalov. HAHAHA Very Happy
His arguments are also of high quality - if I find the discussions with him challenging, it is only because his understanding of the topics is very deep and his responses are always thoughtful.

When working on fasm I sometimes used to think: "this is a weak spot of the design... probably no one will notice".
But nowadays I think: "this is a weak spot of the design... probably l_inc will notice".
Post 24 Feb 2014, 16:23
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
fasmnewbie
Quote:
He can choose many options to confirm this ...

And why do you think, these options are not available when invoking procedures? I could even agree that both approaches are equally applicable in this particular use case if implemented correctly. Thus when considering only this use case you can just say: "Why not macros?"

Quote:
You never cease to post quality codes and solutions...

That's a huge overestimation in the context of this piece of crutch I provided.

Quote:
you are a bit pushy when you argue with Privalov

There are many reasons for what appears to be pushy. Eventually I just add the author's argumentation to my arsenal to be able to argue in fasm's favor elsewhere.

_________________
Faith is a superposition of knowledge and fallacy
Post 24 Feb 2014, 16:30
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
Tomasz Grysztar
Quote:
But nowadays I think: "this is a weak spot of the design... probably l_inc will notice"

LOL. WOW. That's a huge compliment to me. Thank you.

_________________
Faith is a superposition of knowledge and fallacy
Post 24 Feb 2014, 16:34
View user's profile Send private message Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
l_inc wrote:
fasmnewbie
Quote:
He can choose many options to confirm this ...

And why do you think, these options are not available when invoking procedures? I could even agree that both approaches are equally applicable in this particular use case if implemented correctly. Thus when considering only this use case you can just say: "Why not macros?"


There are two reasons why macros serve the purpose better:

1. Codes will get lots and lots messy when using procedures. That's in contrast to the expectations of newbies seeking simple entry into the "unstructured and messy" world of assembly programming.

2. Procs and stacks are Chapter 5 in most assembly syllabus. Forcing them to learn how to deal with stack frame, calls, rets when calling procedures while in "Chapter 1" will surely kill their learning interests.

People may not be aware of this, but FASM's macro might just find its own special use in pedagogy. That's why I told you before, we are on different angles. While you see macros as "code replication", I see macro as an effective learning and teaching "tool".

Quote:
Quote:
You never cease to post quality codes and solutions...

That's a huge overestimation in the context of this piece of crutch I provided.


I was talking about other codes you posted in other threads as well. Keep it up Very Happy

Quote:
Quote:
you are a bit pushy when you argue with Privalov

There are many reasons for what appears to be pushy. Eventually I just add the author's argumentation to my arsenal to be able to argue in fasm's favor elsewhere.
[/quote]

Way to go bro. hehehe Very Happy
Post 25 Feb 2014, 06:24
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
AsmGuru62 wrote:
What about the debugger?
I think the debugger should be used to confirm values in registers and memory.


Hehehe. This is another one of my favorite guru just coming down from the hills of Tibet Laughing

I have nothing against the debugger. But from day 1 I got addicted to FASM/Assembly, I never even once use a debugger, and I still don't know what that is. Most of the answers I got were from this board's guru like you, baldr, revolution, l_inc, John, uart, Baic, Frank Kotler, Bryant Keller (nasm), Codebase, shutdown, dogman and others.

I don't know, maybe I'll have a look, or maybe I just don't need it yet as long as I don't touch Win32 programming :p
Post 25 Feb 2014, 06:35
View user's profile Send private message Visit poster's website Reply with quote
fasmnewbie



Joined: 01 Mar 2011
Posts: 553
fasmnewbie
Tomasz Grysztar wrote:
fasmnewbie wrote:
You never cease to post quality codes and solutions on this board although you are a bit pushy when you argue with Privalov. HAHAHA Very Happy
His arguments are also of high quality - if I find the discussions with him challenging, it is only because his understanding of the topics is very deep and his responses are always thoughtful.

When working on fasm I sometimes used to think: "this is a weak spot of the design... probably no one will notice".
But nowadays I think: "this is a weak spot of the design... probably l_inc will notice".


Man, that's a huge compliment. l_inc, you need to argue more with 'this dude' and see if he can come up with 2.0 this year. hehehe Very Happy
Post 25 Feb 2014, 06:43
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc
fasmnewbie
Quote:
1. Codes will get lots and lots messy when using procedures.

How? I see exactly the opposite. As I said before, procedures contain mostly pure code representing the essential cpu actions for solving a task, while macros require to mix cpu instructions with assembly directives making you think in multiple processing stages in parallel. The latter is much messier and harder to handle.

Quote:
2. Procs and stacks are Chapter 5 in most assembly syllabus.

Well... What chapter are the macrodefinitions and the related fasm quirks? Smile
If you view it from the perspective of a user of your "idea book", then the interface is almost the same:
Code:
;invoking as a macro:
fprt "Your numbers are %d and %d\n",[x],40
;invoking as a procedure:
stdcall fprt, "Your numbers are %d and %d\n",[x],40    

Is your point just about the complexity of typing that additional stdcall in front of the procedure name?

If you view it from the perspective of a developer of macros or procedures, then you still either learn how to write macros or you learn how to write procedures. I can't see how one is easier than the other. Btw. stack usage is equally important for both.

_________________
Faith is a superposition of knowledge and fallacy
Post 25 Feb 2014, 10:29
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1409
Location: Toronto, Canada
AsmGuru62
One day I will write a manual on OllyDbg with images and stuff, so every new coder will be able to debug their code.
Post 25 Feb 2014, 15:23
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >
Forum Rules:
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 vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.