Re: Question about jumps

Dragontamer wrote:
Markus Pitha wrote:

randyhyde@xxxxxxxxxxxxx wrote:

Your problem, as others have pointed out, is that you're not to the
point yet where you understand the difference between the string
representation of an integer and the integer itself.

I understand it, but obviously it's in assembler language more complicated
than I thought, but it's my target to learn exactly these basic things.


Erm...

You can do this in Scheme, C, Lisp, Python, Perl, Haskell, and
Brain***
even.

Sure. And if he wanted to do that, he should get the hell out of here and take it to alt.lang.brain***!

The fact of the matter is that the most common "assembly language" way
is to link up with the C library and then use atoi or whatever.

"Common" in what circles?

But yeah; you can do this in C. In fact; there is an example
in the book "The C programming language" where they solve
this problem.

This has _nothing_ to do with assembly language.

If you do it in Brain*** it doesn't have anything to do with assembly language, either. No ***.

stdout.put( "Enter an integer:" );
stdin.geti32(); // Read integer from stdin into EAX.
shl( 1, eax ); // Multiply EAX by two
stdout.put( "eax = " );
stdout.puti32( eax );

So why should I deal with assembler, when I could solve it with C-like
methods? That's not what I want to learn.

You can't touch eax in C.

return (42);

Are you listening? "That's not what I want to learn." Do we have to wrap it in an "if" and "stdout.put" before you guys can comprehend that?

Now you get to see the effect of the shl instruction without having to
learn all the stuff needed to write your own integer input and output
routines. Sure, at some point you ought to be able to write your own
input and output routines, but for right now the integer I/O routines
in the HLA stdlib are *perfect* for the job.

(don't dislocate your shoulder there, Randy! :)

It's not my target to see what's happened when I type in a number and see
the result on stdout. That's what computer newbies are probably interested
in but I want to understand what the little gremlins in the background are
doing while this happens.


I just fail to see what HLA does that prevents this.

True. (once you've got the file open :) So why don't the HLA fans provide an example that *shows* how the little gremlins work, instead of telling him "just call stdout.put"?

If you want to write your own itoa or atoi routine... assembly
is not the language to do that.

Right. High level languages have some special magic that allows 'em to do it. Are you *listening* to yourself?

Well; you _can_ of course;
just... atoi isn't a "little gremlin" at all.

No, it's a sequence of machine instructions. Markus has made it fairly plain, I thought, that he wants to know what that sequence of instructions *is*.

For that matter; where do the "little gremlins" stop? I mean; all
you're
doing right now is calling the linux kernel. Aka: using the linux
kernel as a library. Where does "read" and "write" come from?

A very good point.

How far will you go before you're satisfied?

*That's* the question! If we start seeing bootsector questions from Markus, we'll know he *wasn't* satisfied with "read" and "write". We already know he's not satisfied with "just call printf".

Most ironically of all is probably the fact that none of your assembly
code would work without the C code that built the Linux kernel.

Another good point. Since "printf" is (highly probably) already in memory, why clutter up memory with a HLA routine that duplicates it? (unless you prefer a routine written in assembly language...)

The *simple* way to do this:

global _start
_start:
mov ebx, 21
shl ebx, 1
mov eax, 1 ; __NR_exit
int 80h

You've gotta type "echo $?" to see the result, and it'll only display the low byte. If that's not acceptable, "printf" is sitting in memory, Not difficult to call it...

; nasm -f elf myprog.asm
; ld -o myprog myprog.o -I/lib/ld-linux.so.2 -lc

; have Nasm tell ld that "_start", the default
; entrypoint, is here
global _start

; tell Nasm that "printf" isn't here
; have ld find it
extern printf

section .data
; pretty standard format string - zero-terminated.
; note that "\n" won't work - that's a
; preprocessor thing - we have to specify
; the linefeed... or printf won't flush
; it's internal buffer! (until exit)
fmt_int db '%i', 10, 0

section .text
_start:

; perform our experiment
mov eax, 21
shl eax, 1

; and print the result - C likes
; its parameters on the stack,
; leftmost one last.
push eax
push fmt_int
call printf

; and C expects caller to clean up stack
; Pascal and the Windows API *don't* do this.
add esp, 8

; return whatever printf returned to us...
; number of items? looks like number of bytes...
mov ebx, eax
mov eax, 1
int 80h
;-------------------

From there, it's an easy step to display the number on the top of the FPU stack. If Markus wants to know how *that* little gremlin works... well... have to find that link to Ray Filiatreault's site... but that, too, is a sequence of machine instructions that can happily be represented in assembly language... (a *lot* more assembly language than displaying an integer!)

Best,
Frank

.

Quantcast