Re: string
From: Frank Kotler (fbkotler_at_comcast.net)
Date: 09/07/04
- Next message: Kain: "Re: Debug.exe for win32"
- Previous message: Randall Hyde: "Re: Helpful Practical Uses of Conditional Assembly"
- In reply to: Kleidemos: "Re: string"
- Next in thread: wolfgang kern: "Re: string"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 07 Sep 2004 04:11:18 GMT
Kleidemos wrote:
> Can anyone test this program??
No. Well, not without rebooting. I haven't become an "uptime freak", I
*swear* I haven't, but I have a strange reluctance to reboot without
some good reason... and dos/doze doesn't seem like a good reason. Really
must install dosemu...
But I think I can spot a couple problems without actually trying it. You
start out printing your title - so far, so good. Then you do the cpuid,
and put the parts of the returned value into a string. I'd have to test
that to be certain - not that familiar with cpuid - but it looks right
to me. Then you print it - problem number one! Int 21h/9 expects the
string it's printing to be terminated with a '$', and will *keep*
printing until it encounters one. This can take a long time, and totally
trash your display. The easiest way to fix this is to extend your
vendorstring to "resb 13", and after (or before, I suppose) putting the
cpuid return(s) into it, do "mov byte [VendorStr + 12], '$'". Other
options would be to initialize the string with a '$' at the end of it -
you'd have to move the string into your ".data" section. Or you could
use a print routine that didn't require a '$' terminator (int 21h/40h
would do it...).
Then comes the real problem! At this point, you're done - this is where
your "exit" wants to go. Instead, you "fall through" into your "print"
routine. This will print VendorStr again (since it's address is still in
dx). Then it hits "ret". Since it hasn't been called, there's no valid
return address for it to return to. In the general case, this could be
very bad - you'll go to whatever garbage location is on the stack, and
start executing code there! In this case - a dos .com file, where you
haven't messed with the stack - you're okay. When dos loads a .com file,
it pushes a zero on the stack, and it's still there, so you'll "return"
to location zero of whatever segment dos loaded you into. That's where
dos puts the "Program Segment Prefix", and the first thing in the PSP is
CD 20, or "int 20h". This ends your program and returns control to dos,
so after having printed VendorStr twice, you exit normally - without
having encountered the "exit" code you wrote at all! You just need to
move the "exit" routine so that you program looks like:
call subroutine
call subroutine
exit:
...
subroutine:
...
ret
instead of:
call subroutine
call subroutine
subroutine:
...
ret
exit:
...
You could, in fact, do it like:
call subroutine
; fall through into subroutine and exit
subroutine:
...
ret
...if you wanted to be "tricky". I'd advise against it. (less clear, and
harder to "maintain"...) The "println" routine is never used, and
represents "bloat", but that isn't really a problem. That's what I think
I can see without trying it... hope it works :)
Best,
Frank
> [BITS 16]
> [ORG 0100h] ; for .com
>
> [SECTION .text]
> start:
> mov dx, Title
> call print
> mov eax, 0
> cpuid
> mov [VendorStr], ebx
> mov [VendorStr+4], edx
> mov [VendorStr+8], ecx
> mov dx, VendorStr
> call print
>
> ; Print a string
> ; Input: Dx => string offset
> print:
> ; set int 21h service 09h
> mov ah, 09h
> int 21h
> ret
> ; Print a string and go to new line
> ; Input: Dx => string offset
> println:
> ; set int 21h service 09h
> mov ah, 09h
> int 21h
> mov dx, NewLine
> call print
> ret
> exit:
> ; set int 21h service 4Ch(exit)
> mov ah, 4Ch
> int 21h
>
> [SECTION .data]
> NewLine db 13, 10, '$'
> Title db "Lucas CPUID program", 13, 10, '$'
>
> [SECTION .bss]
> VendorStr resb 12 ; Reserve 12 bytes for cpu's vendor string
- Next message: Kain: "Re: Debug.exe for win32"
- Previous message: Randall Hyde: "Re: Helpful Practical Uses of Conditional Assembly"
- In reply to: Kleidemos: "Re: string"
- Next in thread: wolfgang kern: "Re: string"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|