Re: which book to start with...?
- From: Frank Kotler <fbkotler@xxxxxxxxxxx>
- Date: Thu, 06 Dec 2007 01:49:15 GMT
naunetr wrote:
Herbert Kleebauer wrote:
....
ok. but your script doesnt look like nasm like given in Duntemann's book.
No? :)
Herbert finds Intel syntax (or Nasm's "Intel-like" syntax) illogical, confusing, and generally distasteful to use. So he uses a "homemade", 68k-like syntax. His assembler, "Lindela" assembles it directly. He has provided, for Nasm users, a set of Macros that approximates his preferred syntax.
but i compiled it anyway. had to set executable bit to make it work,
Yup. Nasm doesn't know to set the executable bit. "Normally", Nasm's output would be a linkable object file, which just needs to be readable by ld - ld sets the executable bit on the executable...
but it works great. amazing only 248 bytes. the c prog i wrote to duplicate this was ~4kb!
Yup. Look how much more "productive" C was! :)
; nasm -O99 -f bin -o d2u d2u.asm
%include "mac.inc" ; ftp://137.193.64.130/pub/assembler/xlinux.zip
;===========================================================================
seg 32
orig equ $08048000
code_addr equ orig
code_offset equ 0
section .text vstart=code_addr
;--------------------------- ELF header -----------------------------------
dc.l $464c457f,$00010101,0,0,$00030002,1,main,$34,0,0,$00200034,2,0
dc.l 1,code_offset,code_addr,code_addr,code_filez,code_memsz,5,4096
dc.l 1,data_offset,data_addr,data_addr,data_filez,data_memsz,6,4096
;--------------------------- code ------------------------------------------
wow. all this is totally above my leval of understanding guys.
And that's just the ELF header! Herbert feels that every byte that appears in the executable ought to be accounted for in the source code. In general, I agree, but I'm willing to let ld add the "OS cruft", so long as it doesn't touch my actual executable code. I like Herbert's method - it's smaller than what I can get get out of ld, and I like "small". One of the many things on my "todo" list is a fully-commented "version" of that ELF header, showing what each byte means, and what the alternatives might be. There's also code around - Chuck posted a version for Fasm and Nasm a while ago - that *reads* the ELF header, and displays what it finds. (similar to objdump or elfdump) If you want to get into the details of the ELF header, it's all documented. Start here, perhaps...
<http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html>
There's a famous comment in the Linux code: "/* you are not expected to understand this */". You can take that approach for now, if you want. It's the executable header, 'nuff said. :)
I've "translated" Herbert's code back to "regular Nasm", and let ld do the job of creating the header. Substantially larger (440 bytes, after "strip -R.comment d2u"), but perhaps "easier to read" (for who? Herbert liked it the way it was!)
I guess you understand that this is to be used as a "filter" - "d2u<dosfile.txt>unixfile.txt"... This version is assembled with "nasm -f elf d2u.asm", and linked with "ld -o d2u d2u.o". There are options - using the "-s" switch to ld will create a smaller file - doing "strip -R.comment d2u" will make it smaller still (and you can skip "-s"). (Nasm users who are unaware of it will probably be appalled to find that Nasm puts its name in a .comment section...).
If you have questions about how it works, just ask... Herbert! :)
Best,
Frank
global _start
section .text
_start:
top:
call getc
cmp eax, byte -1 ; this is our end-of-file indicator
je good_exit
cmp al, 13 ; we're skipping carriage-returns
je top
call putc ; output everything else
jmp short top
good_exit:
mov ebx, 0
mov eax, 1
int 0x80
;----------------
getc:
pushad ; save caller's regs
mov ebx, 0 ; stdin
mov ecx, buf ; address of buffer
mov edx, 1 ; count
mov eax, 3 ; __NR_read
int 0x80
test eax, eax ; this just sets the flags
js getc_error ; if negative, something bad happened
popad ; restore caller's regs
jz nothing_read ; if eax is zero, end-of-file
movzx eax, byte [buf] ; get our character in al/eax
ret ; return to caller
nothing_read:
or eax, byte -1 ; same as "mov eax, -1", but shorter
ret ; return our end-of-file marker
getc_error: ; unlikely, but if error reading stdin
or ebx, byte -1 ; set an exit code, and bail out
mov eax, 1 ; __NR_exit
int 0x80
;----------------------
putc:
pushad ; save caller's regs
mov ebx, 1 ; stdout
mov ecx, buf ; address of buffer
mov [ecx], al ; move al into buffer
mov edx, 1 ; just one char
mov eax, 4 ; __NR_write
int 0x80
cmp eax, byte 1
jne putc_error ; if anything but 1, something's wrong
popad ; restore caller's regs
ret ; return to caller
putc_error: ; again, unlikely
or ebx, byte -1
mov eax, 1 ; __NR_exit
int 0x80
;--------------------
section .bss
buf resb 4
;--------------------
.
- Follow-Ups:
- Re: which book to start with...?
- From: Phil Carmody
- Re: which book to start with...?
- From: naunetr
- Re: which book to start with...?
- References:
- which book to start with...?
- From: naunetr
- Re: which book to start with...?
- From: Herbert Kleebauer
- Re: which book to start with...?
- From: naunetr
- which book to start with...?
- Prev by Date: Re: Tasm IDE
- Next by Date: Re: Sudoku
- Previous by thread: Re: which book to start with...?
- Next by thread: Re: which book to start with...?
- Index(es):
Relevant Pages
|
