Bad habits
in [ASM]
|
From: Frank Kotler on 6 Feb 2006 10:50 Herbert Kleebauer wrote: > Frank Kotler wrote: > > >>do_string: >> lodsb ; get a character into al > > > But don't forget to clear the direction flag. Whoops! Right you are. I always (usually) forget to do that. *I* never set the damn thing down, and it's "almost always" a safe bet that it's up when you get it... but it would screw things up royally if it *was* set down, and it's easy enough to do "cld". If we touch the direction flag in a subroutine, I suppose we should save/restore caller's flags (in case they've got it set down). Is this worthwhile, in your opinion? Is there a "convention" on it? Thanks for catching that, and proving once again, "Herbert doesn't miss much!" Best, Frank
From: Betov on 6 Feb 2006 11:12 Frank Kotler <fbkotler(a)comcast.net> ?crivait news:WsednUfq-eiR9nreRVn- gA(a)comcast.com: > You've stated, in the past, that Fasm's macro language was "more > powerful" than Nasm's. Do you have an example of something Fasm can do, > that Nasm can't? When it comes to syntax... Nasm's macro syntax is > uglier than a bulldog's hind end. Looks like Gas on bad acid! But I > think it's fairly "powerful" (not as much so as Masm or HLA, but > "fairly"...). Says right in the manual it's "powerful"... I did not really studied the NASM Macros, but i can say that when i saw what C_the_Guy did with them, i was simply stuck. 'Powerfull", in matter of Macros Engine does not mean that much. You have to consider "Powerfull at what cost". That is, implementing a Macros Engine doing marvels is not that difficult, but, implementing a Macros Engine that is simple to program, efficient enough for the regular tasks, is a real hard job. In almost all Assemblers, developping a simple and trivial Macro is almost always a long and difficult job, most usually done by several programmers. Now, considering FASM Macros Engine with these spectacles, here is an example of a same Macro for FASM and for RosAsm (Sorry, no example of the NASM version, but, if i recall well, what C_the_Guy did was very close to this...): This is a Macro defining a one Intruction conditional. A one like "If/End_If", if you like, to be used, for example, under the form of: On eax = &TRUE, call Something, Param1, Param2 The FASM version, first: ------------------------------------------------------- macro .on [args] { common local ..on __ON equ ..on match =ARGS v1=s>==v2 =, inst, ARGS args ; .on v1 s>= v2, instruction \{ cmp v1,v2 jl __ON inst ARGS equ \} match =ARGS v1=s<==v2 =, inst, ARGS args ; .on v1 s<= v2, instruction \{ cmp v1,v2 jg __ON inst ARGS equ \} match =ARGS v1=s<v2 =, inst, ARGS args ; .on v1 s< v2, instruction \{ cmp v1,v2 jge __ON inst ARGS equ \} match =ARGS v1=s>v2 =, inst, ARGS args ; .on v1 s> v2, instruction \{ cmp v1,v2 jle __ON inst ARGS equ \} match =ARGS v1>==v2 =, inst, ARGS args ; .on v1 >= v2, instruction \{ cmp v1,v2 jb __ON inst ARGS equ \} match =ARGS v1<==v2 =, inst, ARGS args ; .on v1 <= v2, instruction \{ cmp v1,v2 ja __ON inst ARGS equ \} match =ARGS v1==v2 =, inst, ARGS args ; .on v1 = v2, instruction \{ cmp v1,v2 jne __ON inst ARGS equ \} match =ARGS v1<>v2 =, inst, ARGS args ; .on v1 <> v2, instruction \{ cmp v1,v2 je __ON inst ARGS equ \} match =ARGS v1>v2 =, inst, ARGS args ; .on v1 > v2, instruction \{ cmp v1,v2 jbe __ON inst ARGS equ \} match =ARGS v1<v2 =, inst, ARGS args ; .on v1 < v2, instruction \{ cmp v1,v2 jae __ON inst ARGS equ \} match =ARGS v =, inst, ARGS args ; .on reg/var, instruction \{ if v eqtype 0 if ~ v jmp __ON end if else if v eqtype eax test v,v jz __ON else cmp v,0 je __ON end if inst ARGS equ \} __ON: restore __ON restore ARGS } ----------------------------------------------------------- And now, here is the RosAsm version: [On | cmp #1 #3 | jn#2 M1> | #4>L | M1:] .... which also requires having declared the general purpose Equates: [= e, < b, > a, <s l, >s g, =< be, <= be =>, ae >= ae, <> ne] Once this is said, it is evident for anyone having given the FASM Macros system a try, that it _can_ do incredible things, that the RosAsm Macros System could not do... if one wants to pay the cost... :) Betov. < http://rosasm.org >
From: Betov on 6 Feb 2006 11:18 Frank Kotler <fbkotler(a)comcast.net> ?crivait news:dLKdnQ5dmcP57XreRVn- gQ(a)comcast.com: > If we touch the direction flag in a subroutine, I suppose we should > save/restore caller's flags (in case they've got it set down). Is this > worthwhile, in your opinion? Is there a "convention" on it? No. Inside an Application, there is absolutely no reason for taking any care of the Direction Flag. Its default is off. Once a Routine sets it On, it MUST set it off before leaving. We should consider any violation of this rule as an error as dramatic as forgetting to pop what we have pushed. Betov. < http://rosasm.org >
From: Frank Kotler on 6 Feb 2006 11:38 ?a\/b wrote: .... > it seems to me that read() is not in the "standard C". it seems to me > read() is the system read() for the unix or unix like OS. fread() > should be in the "standard c" but in this case has the need of stdin. > anyway read() could be in the standard posix or other so the borland > linker seems to know that function Okay. I was under the impression that "open", "read", etc. were the "low level" variants, and the "f*" versions were "wrappers". The "f*" stuff does "streams" - I guess that means that the library routines handle buffering for us(?). "open" returns an int, "fopen" returns a "*FILE" (whatever that is), right? I'm quite sure they return different things on error(!). Someone posted some C code to the linux-nasm-users list on Yahoo... /* Open the file for reading and writing */ fbfd = open("/dev/fb0", O_RDWR); if (!fbfd) { printf("Error: cannot open framebuffer device.\n"); exit(1); } printf("The framebuffer device was opened successfully as fd %d\n", fbfd); In case of error, this reports the the framebuffer device was opened successfully as -1 (!!!). I think, a confusion between "open" and "fopen"... This wouldn't apply to stdin/stdout/stderr, as they're already open, and "framebuffer device" wouldn't apply to Windows at all... I may have this completely screwed up - I don't know C. ("I only see what my sick anti-C religion allows me to see." :) > nasmw -f obj this.asm > bcc32 this.obj > > your code with windows - borland is ok if i add '_' in the call for > function puts() and read() The "--PREFIX_" switch should take care of that - if you want to use it. For "ELF-C", which *doesn't* want the underscores, I've been stripping them off by hand, when necessary, but I find that Nasm has a built-in, format-specific macro that'll "%define _%1 %1" for me... > and i add the lines > > section _DATA public align=4 class=DATA use32 > section _BSS public align=4 class=BSS use32 > section _TEXT public align=1 class=CODE use32 > > if i write use32 and not add these line the linker says something like > Fatal: Unsupported 16-bit segment(s) in module this.asm Right. "-f obj" (OMF) is by default a 16-bit format - with 32-bit "extensions". If there's *anything* - code, data, labels - outside of a 32-bit section, Nasm puts it in the default - 16-bit - section... which pisses off the linker. Not an issue with "-f win32", which is 32-bits by default. ("-f obj" for Borland tools, Alink, valx(?)... others? "-f win32" for MS link, polink, Mingw/Cygwin ld,... others?) Nice to have two ways to make Windows files, but it does add to the confusion... Best, Frank
From: Herbert Kleebauer on 6 Feb 2006 12:22
Betov wrote: > Frank Kotler <fbkotler(a)comcast.net> ?crivait news:dLKdnQ5dmcP57XreRVn- > > > If we touch the direction flag in a subroutine, I suppose we should > > save/restore caller's flags (in case they've got it set down). Is this > > worthwhile, in your opinion? Is there a "convention" on it? > > No. Inside an Application, there is absolutely no reason > for taking any care of the Direction Flag. Its default > is off. Is there an official Microsoft documentation which specifies that the direction flag is cleared when control is given to the first instruction in a PE executable? > Once a Routine sets it On, it MUST set it off > before leaving. We should consider any violation of this > rule as an error as dramatic as forgetting to pop what > we have pushed. You can do this for your own subroutines, but any call to a library function (DLL or statically linked) can modify the direction flag. |