Re: which book to start with...?

naunetr wrote:

....
will Herbert's elf header still work when linking several object files to form the executable?

No. We could, using Nasm's binary output format, generate a "linkable format" header suitable for static linking, I suppose... but Nasm has that capability. We *can* link to a dynamic library (.so - "shared object" files) Stephen Pelc has expanded on Brian Raiter's "Teensy" work, with an example of calling printf without a linker:

http://www.mpeforth.com/arena/cwgtLinux.txt

Put that on the back burner with the "Teensy" tutorial. This isn't strictly about "Assembly Language", but how to interface with the OS... which we *do* have to do, but we don't really need to know the details to do some "Assembly Language".

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! :)

when syscall macro is used instead of fread size of c executable is down to 2928 bytes, 4 times bigger than asm version. :)

Yeah... You can probably improve on that. Long ago, someone - Jerry Coffin, I think - showed how to make a "small" hello world in C, by writing a custom "crt.o" instead of the default "startup code" - *just* "call main", as I recall - the default code does quite a bit more. Still smaller in asm. (some question whether this is a "big deal" or not, but the opposite "bloat doesn't matter" gives... well, what we see!)

....
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.

i guess thats possible only in machine code?

Well... it's "assembly language". Not "executable code", but "just bytes". Results in "just bytes", that is. Some of the values are the result of calculating expressions at assemble-time, not at run-time. so it isn't really "machine code" in that sense.

The CPU *would* execute it, if we jumped into it. A dos .com file will actually execute an ELF header without any harm - once we get to a "don't care" part of the header, we can insert a "jmp my_16bit_code", and create an executable that will run on dos *and* Linux. A "trick" - not useful for anything I'm aware of.

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".

still when c library is called instead of read syscall the size becomes many times more.

For an interesting experiment, try a hello world with printf and linked statically. Around 400k, IIRC! :) Any use of the shared libraries involves adding some "dynamic linker" code to your executable. It's mostly a "one time" cost, I think, so the difference isn't going to be as many "times" larger in a more extensive program (still...!)

and my java app for the same thing is only 447 bytes but at runtime it takes 200Mb of memory!!

That's impressive - on both ends! I don't know anything about Java. Tried to help my daughter with homework when she was taking a course in Java... Learned just enough to determine that it's not "my cup of tea". Interesting concept, though.

....
(Nasm users who are unaware of it will probably be appalled to find that Nasm puts its name in a .comment section...).

i saw that when i looked at the executable in vim's hex viewer. i think the 0.98.39 version didn't do this?

I think it's done it from "day one". Not really sure. Possibly already been removed from the binary you were looking at? (or maybe made with "-f bin"?).

is there any chace that strip can damage execute or object files or is it always safe to use even with s option?

I don't know. I assume strip has been around, and been "massaged" enough to be "safe". I've never had a problem with it. Other tools (objdump?) seem to do less well with stripped executables. Some of the "bloat" we're eliminating is "useful", even though not necessary for the thing to execute.

also noticed that even strip -s doesnt remove the nasm comment from readc. so nasm creates a separate .comment section? what if users code already has a .comment section? nasm adds to it? ;)

I imagine so. (tries it...) Nasm complains about "redefined section name". I don't know how to add to the .comment section - if we can. Adding an arbitrarily named "section foo" with "my comment" in it happens to be contiguous with "The Netwide Assembler..."

....
test eax, eax ; this just sets the flags


okay i have look this instruction up. i only cmp for now.

"cmp eax, 0" would do the same.

nasm manual says test does a bitwise and of its operands and affects the "flags". so this would do an and with identical values.

Right. "cmp" is an "imaginary sub" - flags are set as if a subtraction were done, but the result isn't stored in the "destination" register. "test" is an "imaginary and" (bitwise) - the result isn't stored, but the flags are set.

js getc_error ; if negative, something bad happened


nasm manual says this jumps to operand when sign flag is set. but i dont understand how the previous test will set the sign flag.

The sign flag is set if the most significant bit in the result is set. If the value is being interpreted as "signed", this would mean it's negative. (it *doesn't* tell us if the value is signed or unsigned, and is meaningless if it's unsigned) "How does the CPU know if a number is signed or unsigned?" It doesn't - *we* have to provide appropriate instructions, when it matters. For example:

mov al, 0FFh ; could mean 255 or -1
mov bl, 1
cmp al, bl
ja someplace ; taken 255 greater than 1 (unsigned)
jg someplace ; not taken -1 not greater than 1 (signed)

never mind, i guess PGU explains this sort of stuff...

Yes.

....
nothing_read:
or eax, byte -1 ; same as "mov eax, -1", but shorter

but my c book says that end of file is normal

Yes. Or we'd need bigger hard drives! :)

so shouldnt we return zero instead of -1?

Good point. We could, here, since we aren't likely to encounter a 0 byte in a text file. In a more "generic" filter, which might be suitable to process a binary file, we might get 0 as a valid byte, we couldn't tell from the 0 whether it was a valid byte or EOF. The "movzx" clears the upper part of eax... so anything 0..0FFh is a valid byte, *all* of eax being set to 1s is EOF...

also shouldn't popad be just before the ret under nothing_read?

It needs to be "before", but not necessarily "just" before. You'll notice that the "popad" is done before *either* of the returns, but isn't done for the "error exit" (since we don't care). Might be clearer to have a separate "popad" just before each "ret", but it's "right" the way it is.

....
okay i think i can generally understand the other portions. in c stdin, stdout and stderr are preopened when app starts. is this the same even when only using kernel?

Yeah.

when writing readc i had thought that i should do a open with 0

I'm not sure how you did that.

before reading but i tried it without and it works, so i guess stdin, stdout and stderr are opened already by kernel when app starts?

Yeah. Seems to be...

i like this method better than push ...

There are advantages to both.

needed with c library. no need to pop anything also. also the reverse order in c is confusing :)

As usual, which order is "reversed" depends on gow you look at it. The way I keep it straight, for C, is that the "nearest" parameter to the "printf" or whatever is "nearest" up the stack from my routine...

in nasm html manual the x86 instruction refarence is not linked in contents page. i had to load nasmdocb.html directly.

I don't know what version you've got - in latest versions, the instruction set reference has been removed entirely (no volunteers to keep it current). Perhaps you've got a new manual with "nasmdocb.html" left over from an earlier install? Not a bad idea - I find Nasm's version of the instruction set reference useful, even though it isn't up-to-date (and has errors).

There are a number of instruction set references on the web (besides Intel/AMD manuals) This is just the first one I came across...

http://home.comcast.net/~fbui/intel.html

So...I think it's "too bad" that the section was removed from the Nasm manual, but it isn't a total loss...

Best,
Frank
.

Relevant Pages

  • Re: which book to start with...?
    ... Herbert finds Intel syntax illogical, confusing, and generally distasteful to use. ... And that's just the ELF header! ... There's also code around - Chuck posted a version for Fasm and Nasm a while ago - that *reads* the ELF header, ... is there any chace that strip can damage execute or object files or is it always safe to use even with s option? ...
    (alt.lang.asm)
  • Re: which book to start with...?
    ... The CPU *would* execute it, ... a hello world app with a infinite loop indicates ~10Mb of physical memory use in top. ... that Nasm puts its name in a .comment section...). ... anyway now my 0.98.39 install was overwritten by 2.0 compilation. ...
    (alt.lang.asm)
  • Re: Forth for Mac OS X Leopard (Intel) - what are the options?
    ... toolchain to assemble and link a working lina binary, ... it, you can execute it. ... (or segments I still do not understand fully the difference - nasm ...
    (comp.lang.forth)
  • Re: Why this toy code wont execute on Intel Linux platform??
    ... >and making an executable with gcc after NASM makes a .o file. ... Linux cannot execute 16-bit applications from ...
    (comp.lang.asm.x86)
  • Re: Determining whether an applications has thrown some error ...
    ... set some flag and check the flag whether error is thrown or not ... ... It depends on where the error happens and what type it is versus where you want to execute the code. ... If the error is an exception (as your use of the word "thrown" implies) you can put the code in a catch block and it will execute "immediately" after the error is thrown (depending on the rest of the code). ...
    (microsoft.public.dotnet.languages.csharp)