Bad habits
in [ASM]
|
From: Frank Kotler on 5 Feb 2006 21:48 James Daughtry wrote: > I'm not sure if this is as good a place as comp.lang.asm.x86 <giggles uncontrollably> .... > %macro invoke 2 > push %2 > call %1 > add esp,4 > %endmacro Okay, for a start, but only takes one parameter. .... > extern _gets .... > Yes, I know gets is dangerous, but I couldn't figure out how to supply > stdin to fgets... Right. Any other bad habits pale by comparison!!! I don't know "fgets" - "symbols-guy" says it takes "__streams" (???). I'd use "sys_read" - I guess the 'doze equivalent would be "_ReadFile(a)20" (???). Anyway, C's "read" works much like "sys_read"... Here's the way I'd do it (well... it's the way I'd do it if I were into C)... Best, Frank ; displays characters user inputs as binary ; nasm -f elf str2bin.asm ; (tested) ; ; or... if you haven't got Linux: ; nasmw -f win32 --PREFIX_ str2bin.asm ; (changes "main" to "_main", "puts" to "_puts", etc.) ; (untested!) ; ; gcc -o str2bin str2bin.o global main extern puts extern read BUFSIZ equ 256 STDIN equ 0 section .data prompt db 'Enter some text to be displayed as binary:', 0 section .bss inbuf resb BUFSIZ outbuf resb BUFSIZ * 9 + 1 ; 8 bits plus space per input byte ; plus one for terminating zero section .text main: push ebx ; save caller's regs push esi push edi push prompt call puts add esp, byte 4 push BUFSIZ - 1 ; (maximum) length push inbuf ; buffer push byte STDIN ; file descriptor/handle call read add esp, byte 12 ; zero-terminate our string! ; ("read" returns number read, ; including the newline, in eax) mov byte [inbuf + eax - 1], 0 mov esi, inbuf mov edi, outbuf do_string: lodsb ; get a character into al cmp al, 0 ; end of string? jz done mov ecx, 8 ; 8 bits to do do_char: rol al, 1 ; MSB into carry-flag (and LSB) push eax ; save temporary result mov al, '0' ; character '0', not number 0 adc al, 0 ; bump to '1' if carry set stosb ; save in output buffer pop eax ; restore temporary result loop do_char ; do all 8 bits mov byte [edi], ' ' ; and a spacer between characters inc edi ; next character position jmp short do_string ; until done... done: stosb ; zero terminate string (al is already zero) push outbuf call puts add esp, byte 4 xor eax, eax ; return 0 pop edi ; restore caller's regs pop esi pop ebx ret ;---------------
From: Dragontamer on 5 Feb 2006 23:59 \\\o///annabee wrote: > På Sun, 05 Feb 2006 21:55:21 +0100, skrev Herbert Kleebauer > <klee(a)unibwm.de>: > > > James Daughtry wrote: > > > > But because it doesn't make any sense to write > > an application in assembler, RosAsm is useful for ...? > > I agree with many things you say Herbert, but the above sentance is really > untrue. Have you tried writing something with RosAsm? > > It is not only that RosAsm, of course, is the best tool for learning > assembly. But it is evidently also the best tool for doing Windows > programming. You _cannot_ see this without trying. Its impossible to find > all the goodies of RosAsm when not using it over time. > > RosAsm doesnt have any other shortcommings, then the ones it was never > designed for. For windows programming it is simply the very best tool yet > available. This is one of the points I like to debate on because I follow a strange philosophy. I feel the best tool for the job is the best *language* for the job, and that tools should be built to allow easy interphasing between languages. Multi-language programming, in essence. The reason is simple: Assembly is by far the best thing to use if you need speed (especially with these MMX and SSE instructions), but rewriting a game into Assembly for speed isn't smart if graphics are slowing you down. Rewriting the program to use DirectX or OpenGL would create a much bigger increase in speed than Assembly. Basically: use the right tool for the job. Another example: Scheme is a language that is a favorite among AI programmers. However, Scheme doesn't work well with external libraries, and its many implementations don't give it really any libraries for it to work with. The solution? Write the majority of the program in C/C++/ObjC, and then *embed* Scheme into C. Write the AI part in Scheme, and everything else in C (or C++). Because most Schemes are interpreters, this gives even a greater advantage as you no longer have to compile your program to make a significant change. So to change the AI to your chess game or whatnot would not require 5 minutes of recompiling, while you can still write in portable GTK+ library (or wxWidgets for C++), which would give you somewhat portability, easy modifications, and using the languages to their maximum potential. Need a quick-and-dirty solution? Use TCL/tk (for Unix/Linux users) or Visual Basic (for you Windows users) which lets you create a GUI in minutes. (and in the case of TCL/tk, no need for a compile cycle makes it a joy. I personally haven't done VB so... yeah...) Use perl for a quicky text application, or awk or sed even if it is simple enough. Batch or shell files are great here too. And with Visual Basic.NET avaliable, you can mix VB.Net code with C# on the new .NET or Mono platforms. And for *nix, TCL and perl interphase with C/C++ fine (just like Scheme example) Portability a major concern? Use Java, Python, Ruby. Web development? PHP, ASP.NET, with some sort of SQL library. Prototyping? Python, Obj-C (Cocoa or GNUstep), or VB again. Use a point-and-click wizard avaliable for and impress your client. If They don't like how the window looks, it is a point-and-click away. This is why I cannot believe there to be one "windows application" tool, because there will always be a case where one of these tools will out-perform another tool. I don't believe in a "one language to rule them all" to any programming problem. --Dragontamer
From: Dragontamer on 6 Feb 2006 00:05 ¬a\/b wrote: > >Yes, I know gets is dangerous, but I couldn't figure out how to supply > >stdin to fgets... > > easy, you write in a c file for your favorite c compiler > > "fgets(array, 256, stdin);" > > and you say to compiler that you want the assembly file out > then you see in the assembly file the name the compiler traslate > "stdin"; than use that name stdin is only pointer to a fstream in C, so all you have to do is extern stdin (or _stdin for windows) and then supply stdin to fgets. If i remember correctly... well, try it anyway. --Dragontamer
From: Herbert Kleebauer on 6 Feb 2006 04:29 Frank Kotler wrote: > do_string: > lodsb ; get a character into al But don't forget to clear the direction flag.
From: ?a/b on 6 Feb 2006 04:41
On Sun, 05 Feb 2006 21:48:31 -0500, Frank Kotler <fbkotler(a)comcast.net> wrote: >James Daughtry wrote: >> I'm not sure if this is as good a place as comp.lang.asm.x86 ><giggles uncontrollably> > >... >> %macro invoke 2 >> push %2 >> call %1 >> add esp,4 >> %endmacro > >Okay, for a start, but only takes one parameter. > >... >> extern _gets > >... >> Yes, I know gets is dangerous, but I couldn't figure out how to supply >> stdin to fgets... > >Right. Any other bad habits pale by comparison!!! I don't know "fgets" - >"symbols-guy" says it takes "__streams" (???). I'd use "sys_read" - I >guess the 'doze equivalent would be "_ReadFile(a)20" (???). Anyway, C's >"read" works much like "sys_read"... 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 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() 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 |