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
> %macro invoke 2
> push %2
> call %1
> add esp,4
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
; displays characters user inputs as binary
; nasm -f elf str2bin.asm
; or... if you haven't got Linux:
; nasmw -f win32 --PREFIX_ str2bin.asm
; (changes "main" to "_main", "puts" to "_puts", etc.)
; gcc -o str2bin str2bin.o
BUFSIZ equ 256
STDIN equ 0
prompt db 'Enter some text to be displayed as binary:', 0
inbuf resb BUFSIZ
outbuf resb BUFSIZ * 9 + 1 ; 8 bits plus space per input byte
; plus one for terminating zero
push ebx ; save caller's regs
add esp, byte 4
push BUFSIZ - 1 ; (maximum) length
push inbuf ; buffer
push byte STDIN ; file descriptor/handle
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
lodsb ; get a character into al
cmp al, 0 ; end of string?
mov ecx, 8 ; 8 bits to do
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...
stosb ; zero terminate string (al is already zero)
add esp, byte 4
xor eax, eax ; return 0
pop edi ; restore caller's regs
From: Dragontamer on 5 Feb 2006 23:59
> På Sun, 05 Feb 2006 21:55:21 +0100, skrev Herbert Kleebauer
> > 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
This is one of the points I like to debate on because I follow a
I feel the best tool for the job is the best *language* for the job,
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
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
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
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"
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
From: Dragontamer on 6 Feb 2006 00:05
> >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.
From: Herbert Kleebauer on 6 Feb 2006 04:29
Frank Kotler wrote:
> 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
>James Daughtry wrote:
>> I'm not sure if this is as good a place as comp.lang.asm.x86
>> %macro invoke 2
>> push %2
>> call %1
>> add esp,4
>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
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