Index
> Macroinstructions > fprint "%d = %b \n",[x],[y]Goto page 1, 2 Next |
| Author |
|
|
baldr 21 Feb 2014, 18:29
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). |
|||
21 Feb 2014, 18:29 |
|
|
fasmnewbie 23 Feb 2014, 08:37
baldr wrote: fasmnewbie, 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. |
|||
|
23 Feb 2014, 08:37 |
|
|
l_inc 23 Feb 2014, 13:39
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 |
|||
|
23 Feb 2014, 13:39 |
|
|
fasmnewbie 23 Feb 2014, 14:57
l_inc wrote: fasmnewbie 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  |
|||
|
23 Feb 2014, 14:57 |
|
|
l_inc 23 Feb 2014, 17:50
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"  . 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 |
|||
|
23 Feb 2014, 17:50 |
|
|
fasmnewbie 23 Feb 2014, 19:32
Then let me, please, try to understand your view....
OK...
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. |
|||
|
23 Feb 2014, 19:32 |
|
|
fasmnewbie 23 Feb 2014, 20:14
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 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
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 |
|||
|
23 Feb 2014, 20:14 |
|
|
l_inc 23 Feb 2014, 21:01
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 |
|||
|
23 Feb 2014, 21:01 |
|
|
fasmnewbie 24 Feb 2014, 12:34
Quote:
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. |
|||
|
24 Feb 2014, 12:34 |
|
|
fasmnewbie 24 Feb 2014, 12:55
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: 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 |
|||
|
24 Feb 2014, 12:55 |
|
|
AsmGuru62 24 Feb 2014, 16:10
What about the debugger?
I think the debugger should be used to confirm values in registers and memory. |
|||
|
24 Feb 2014, 16:10 |
|
|
Tomasz Grysztar 24 Feb 2014, 16:23
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 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". |
|||
|
24 Feb 2014, 16:23 |
|
|
l_inc 24 Feb 2014, 16:30
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 |
|||
|
24 Feb 2014, 16:30 |
|
|
l_inc 24 Feb 2014, 16:34
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 |
|||
|
24 Feb 2014, 16:34 |
|
|
fasmnewbie 25 Feb 2014, 06:24
l_inc wrote: fasmnewbie 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:
I was talking about other codes you posted in other threads as well. Keep it up
Quote:
Way to go bro. hehehe |
|||
|
25 Feb 2014, 06:24 |
|
|
fasmnewbie 25 Feb 2014, 06:35
AsmGuru62 wrote: What about the debugger? Hehehe. This is another one of my favorite guru just coming down from the hills of Tibet 
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 |
|||
|
25 Feb 2014, 06:35 |
|
|
fasmnewbie 25 Feb 2014, 06:43
Tomasz Grysztar wrote:
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 |
|||
|
25 Feb 2014, 06:43 |
|
|
l_inc 25 Feb 2014, 10:29
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? 
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 |
|||
|
25 Feb 2014, 10:29 |
|
|
AsmGuru62 25 Feb 2014, 15:23
One day I will write a manual on OllyDbg with images and stuff, so every new coder will be able to debug their code.
|
|||
|
25 Feb 2014, 15:23 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|