confused asm newbie

confused asm newbie

[Jason Roberts]

I have a few questions concerning how the stack is used and how memory is 
accessed
and what it looks like.I've read books, which only serve to confuse me, or 
the author tries
to mystify you into believing assembly is dark magic only for the elite.
Thanks in advance for any help and/or suggestions--

   in C  If I code char *p = "hello" then *p will be 'h' and *(p+1) will be 
'e', and likewise
   p[4] will derefrence byte 5 ,which is 'o'.If I  ++p  the value at p  will 
be whatever is at the address        of the next byte,etc

   now, how does this relate to asm registers???
   based on code below  'msg' (line 5) is a pointer or 'label' which 
represents an address which             holds 3              bytes plus 
LF,CF,and NULL.
   based on my current understanding--
    msg = address of first byte
   [msg] = value at base,'a'
   add [msg],4 adds ascii value 4 to 'a' so it's now 'e'
   add msg,3   adds 3 to pointer, so msg is now base+3, so  now [msg] should 
be 'c'
   am I right on this???

    also, when I used edi to store string in _start (line 61)  I mov'ed 
'string' without the brackets
    for some reason the use of brackets is neccessary in the case of
    msg (line 84) ...why so?
    also, the stack issue:
    based on my knowledge the stack grows downward but reads upward, i.e. if 
I push
    edi then I have pushed 4 bytes onto stack- and so sp decrements 4 times 
and points
    at last item pushed.  Sp only points to top of stack and knows nothing 
about memory below
    unless we tell it too by explicityly moving it down,which is allocating 
space basically,malloc()
    for the C gang. Am I getting it?
    My only concern is this:
    what does edi look like after line 84???
    we have 6 bytes going into a 4-byte register...
    my guess is:
    6162630a with the CR and NULL being ignored.
    If I'm right then what does the stack look like after the push?
    From what I see the values in the registers are pushed from the low-byte 
up to high so
    that 61 is on top of stack, or worded differently, esp holds the address 
of where 61 is.

    If I got all this right say Kudos! ,otherwise please point me narrow--
    Thankyou for your time and patience.
     Paul


line 1:  section .data
line 2:
line 3:  string     db "Hello insanity!",10,13,0
line 4:  error_msg  db "Null Pointer!",10,13,0
line 5:  msg        db "abc",10,13,0
line 6:
line 7:
line 8:
line 9:  section .text
line 10:
line 11:  global _start
line 12:
line 13:  jmp _start
line 14:
line 15:  ;routine which puts length of string at es:edi into ecx and 
returns
line 16:  get_len:
line 17:           jmp chk_edi
line 18:
line 19:  _inc:
line 20:           inc ecx
line 21:   jmp scan
line 22:
line 23:   ;check that edi is not null or scasb will fail
line 24:  chk_edi:
line 25:           or edi,edi
line 26:           cmovz eax,edi
line 27:   dec eax
line 28:           ret
line 29:
line 30:
line 31:  scan:
line 32:
line 33:   scasb
line 34:           jne _inc
line 35:           ret ; but what if first byte is null? well when ret we 
will check now wont we!
line 36:
line 37:
line 38:
line 39:  error:
line 40:
line 41:
line 42:   mov  edx,15     ;length of buffer
line 43:   mov  eax,4  ;sys_write
line 44:   mov  ebx,1       ;file descriptor
line 45:   mov  ecx,error_msg  ;buffer
line 46:
line 47:   int  0x80
line 48:
line 49:
line 50:           mov ebx,-1
line 51:   mov eax,1
line 52:   int 0x80
line 53:
line 54:
line 55:
line 56:
line 57:  _start:
line 58:
line 59:   mov eax,0 ;used for scasb
line 60:   mov ecx,0 ;will be the length value of string,init to  0
line 61:   mov edi,string    ;if  given null will produce an exception-- 
which I handle
line 62:   cld
line 63:   call get_len
line 64:   cmp eax,0
line 65:           js error
line 66:
line 67:
line 68:
line 69:  write:
line 70:
line 71:           or ecx,ecx       ;check if string was null
line 72:   jz exit          ; could implement exception handler
line 73:   mov  edx,ecx     ;length of buffer
line 74:   mov  eax,4  ;sys_write
line 75:   mov  ebx,1       ;file descriptor
line 76:   mov  ecx,string  ;buffer
line 77:
line 78:   int  0x80
line 79:
line 80:
line 81:
line 82:
line 83:  _test:
line 84:           mov edi,[msg]
line 85:           push edi
line 86:
line 87:           mov  edx,4         ;length of buffer
line 88:   mov  eax,4    ;sys_write
line 89:   mov  ebx,1         ;file descriptor
line 90:   mov  ecx,esp       ;buffer
line 91:   add  dword [ecx],4 ;ecx should be 'e'
line 92:           int  0x80
line 93:
line 94:   ;will print 'ebc' on stdout
line 95:
line 96:
line 97:  exit:
line 98:
line 99:   mov ebx,eax
line 100:   mov eax,1
line 101:   int 0x80

_________________________________________________________________

_________________________________________________________________
Enjoy MSN 8 patented spam control and more with MSN 8 Dial-up Internet 
Service.  Try it FREE for one month!   http://join.msn.com/?page=dept/dialup

Re: confused asm newbie

[Frederic Marmond]

Jason Roberts wrote:

> I have a few questions concerning how the stack is used and how memory 
> is accessed
> and what it looks like.I've read books, which only serve to confuse 
> me, or the author tries
> to mystify you into believing assembly is dark magic only for the elite. 

? I though it was really dark magic only for the elite !
;)

>
> Thanks in advance for any help and/or suggestions--
>
>   in C  If I code char *p = "hello" then *p will be 'h' and *(p+1) 
> will be 'e', and likewise
>   p[4] will derefrence byte 5 ,which is 'o'.If I  ++p  the value at p  
> will be whatever is at the address        of the next byte,etc
>
>   now, how does this relate to asm registers??? 

First thing:
I think you are not really a newbie, so, you problably already know 
that, but keep in mind that C is a typed langage, and ASM is not.
That's to say, a register can not know what type is the data it holds.
mov al,[foobar]
=> get 1 byte from @ foobar, and put it to the 1 byte al register
move edi,[foobar]
=> get the 4 bytes at @ msg, and put them into the 4 bytes edi register.

Ok?
The bytes you take as input are a memory region, pointed by the foobar 
variable. It may be a part of a pixels image, a part of a sound, of a 
text, of binary code, ...

Some assembleurs allows a pre-processing to check for data types, but it 
is not always the case.

When you use:
mov al,[foobar]
foobar is an offset in the memory, and the [] says to the compilator to 
get the data at this address (pointer)
but a
mov al,foobar
will (fail if the compilator check for data types => 32 bits fit into a 
8 bit register) or get the 8 lower bits from the foobar value (the 
address) and store them into al

It's the same as the '*' in C
foobar value;foobar *ptr;ptr=&value
ptr => the pointer (foobar)
*ptr=>the value pointed ([foobar])

Now, your questions:

>
>   based on code below  'msg' (line 5) is a pointer or 'label' which 
> represents an address which             holds 3              bytes 
> plus LF,CF,and NULL.
>   based on my current understanding--
>    msg = address of first byte
>   [msg] = value at base,'a'
>   add [msg],4 adds ascii value 4 to 'a' so it's now 'e'
>   add msg,3   adds 3 to pointer, so msg is now base+3, so  now [msg] 
> should be 'c'
>   am I right on this???
>
>    also, when I used edi to store string in _start (line 61)  I mov'ed 
> 'string' without the brackets
>    for some reason the use of brackets is neccessary in the case of
>    msg (line 84) ...why so?
>    also, the stack issue:
>    based on my knowledge the stack grows downward but reads upward, 
> i.e. if I push
>    edi then I have pushed 4 bytes onto stack- and so sp decrements 4 
> times and points
>    at last item pushed.  Sp only points to top of stack and knows 
> nothing about memory below
>    unless we tell it too by explicityly moving it down,which is 
> allocating space basically,malloc()
>    for the C gang. Am I getting it?

[FYI]
On x86, you have several modes in which your CPU can operate (to keep 
simple, Real mode (16 bits, 64ko segments), and protected mode(32bits, 
up to 4go 'segments')).
Linux runs in protected mode (the most powerfull mode).
In that mode, you can tell the stack to grow up or to grow down. The 
most often, it keep the default, growing downward.
[/FYI]

>
>    My only concern is this:
>    what does edi look like after line 84???
>    we have 6 bytes going into a 4-byte register...
>    my guess is:
>    6162630a with the CR and NULL being ignored. 

Yes, it's true: only 4 bytes can stand into a 4 bytes register... (or 
sign a software pattent, you have created a ziped register! ;))

>
>    If I'm right then what does the stack look like after the push? 

it will contain the "abc\10" string

>
>    From what I see the values in the registers are pushed from the 
> low-byte up to high so
>    that 61 is on top of stack, or worded differently, esp holds the 
> address of where 61 is.

it depends on which system you are (little/big endian).
I don't remember on little endian (x86) if bytes or words are swaped..

>
>    If I got all this right say Kudos! ,otherwise please point me narrow--
>    Thankyou for your time and patience. 

have fun!

>
>     Paul
>
>
> line 1:  section .data
> line 2:
> line 3:  string     db "Hello insanity!",10,13,0
> line 4:  error_msg  db "Null Pointer!",10,13,0
> line 5:  msg        db "abc",10,13,0
> line 6:
> line 7:
> line 8:
> line 9:  section .text
> line 10:
> line 11:  global _start
> line 12:
> line 13:  jmp _start
> line 14:
> line 15:  ;routine which puts length of string at es:edi into ecx and 
> returns
> line 16:  get_len:
> line 17:           jmp chk_edi
> line 18:
> line 19:  _inc:
> line 20:           inc ecx
> line 21:   jmp scan
> line 22:
> line 23:   ;check that edi is not null or scasb will fail
> line 24:  chk_edi:
> line 25:           or edi,edi
> line 26:           cmovz eax,edi
> line 27:   dec eax
> line 28:           ret
> line 29:
> line 30:
> line 31:  scan:
> line 32:
> line 33:   scasb
> line 34:           jne _inc
> line 35:           ret ; but what if first byte is null? well when ret 
> we will check now wont we!
> line 36:
> line 37:
> line 38:
> line 39:  error:
> line 40:
> line 41:
> line 42:   mov  edx,15     ;length of buffer
> line 43:   mov  eax,4  ;sys_write
> line 44:   mov  ebx,1       ;file descriptor
> line 45:   mov  ecx,error_msg  ;buffer
> line 46:
> line 47:   int  0x80
> line 48:
> line 49:
> line 50:           mov ebx,-1
> line 51:   mov eax,1
> line 52:   int 0x80
> line 53:
> line 54:
> line 55:
> line 56:
> line 57:  _start:
> line 58:
> line 59:   mov eax,0 ;used for scasb
> line 60:   mov ecx,0 ;will be the length value of string,init to  0
> line 61:   mov edi,string    ;if  given null will produce an 
> exception-- which I handle
> line 62:   cld
> line 63:   call get_len
> line 64:   cmp eax,0
> line 65:           js error
> line 66:
> line 67:
> line 68:
> line 69:  write:
> line 70:
> line 71:           or ecx,ecx       ;check if string was null
> line 72:   jz exit          ; could implement exception handler
> line 73:   mov  edx,ecx     ;length of buffer
> line 74:   mov  eax,4  ;sys_write
> line 75:   mov  ebx,1       ;file descriptor
> line 76:   mov  ecx,string  ;buffer
> line 77:
> line 78:   int  0x80
> line 79:
> line 80:
> line 81:
> line 82:
> line 83:  _test:
> line 84:           mov edi,[msg]
> line 85:           push edi
> line 86:
> line 87:           mov  edx,4         ;length of buffer
> line 88:   mov  eax,4    ;sys_write
> line 89:   mov  ebx,1         ;file descriptor
> line 90:   mov  ecx,esp       ;buffer
> line 91:   add  dword [ecx],4 ;ecx should be 'e'
> line 92:           int  0x80
> line 93:
> line 94:   ;will print 'ebc' on stdout
> line 95:
> line 96:
> line 97:  exit:
> line 98:
> line 99:   mov ebx,eax
> line 100:   mov eax,1
> line 101:   int 0x80
>
> _________________________________________________________________
>
> _________________________________________________________________
> Enjoy MSN 8 patented spam control and more with MSN 8 Dial-up Internet 
> Service.  Try it FREE for one month!   
> http://join.msn.com/?page=dept/dialup
>
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-assembly" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: confused asm newbie

[willy meier]

Jason Roberts wrote:
> 
> I have a few questions concerning how the stack is used and how memory is
> accessed
> and what it looks like.I've read books, which only serve to confuse me, or
> the author tries
> to mystify you into believing assembly is dark magic only for the elite.

don't get discuraged by those utterly stupid people...
I hope, the following helps to de-mystify:


"Machine-Level Representations of C Programs on Linux/IA32", 
	http://www.lxhp.in-berlin.de/lhplinks.html#cas

also, the System-V & POSIX documents specify the C to asm translation, 
	http://www.lxhp.in-berlin.de/lhplinks.html#sysv

and, if you compile with the following options to the assembler, you'll
get the complete asm listing from compiling a C program, piped into the
file 'LOG.m':

	CFLAGS += -Wa,-acdlms -save-temps
	make (or 'cc' or any other appropriate command) 2>&1 | tee -a LOG.m

tracing with the 'ald' debugger and tests with 'strace' and 'ltrace'
would also return much information about programs execution (links on
above mentioned page).

best,
	hp

-- 
Linux,Assembly,Forth: http://www.lxhp.in-berlin.de/index-lx.shtml
  >> xxxx -at- lxhp -dot- in-berlin -dot- de <<

Re: confused asm newbie

[Philip Jacob Smith]

On Thu, 23 Oct 2003 12:03:44 +0000, Jason Roberts <v3ct0r99@hotmail.com> wrote:

It looks like you're using NASM, so I'll try to help.

> add msg,3   adds 3 to pointer, so msg is now base+3, so  now [msg] should be 'c'

Yeah, except that you can't do that.  msg isn't an actual vairable, but rather it's a constant set at compile time (or more probably at linking time).  If the assembler/linker determines that the msg string is going to be at 0x82214334, then it goes through and writes this into the code, so that the above would be the same as: (if it were possible, that is)

add 0x82214334, 3

Which wouldn't make sense since the value isn't saved anywhere.  To do what you meant, you need to move that constant into a register.

mov eax, msg
add eax, 3

now eax == msg + 3 and [eax] == [msg+3] == 'c'

It's also perfectly valid to just use [msg+3] in instructions, as well as other things like [eax + msg + 3] and such.

> also, when I used edi to store string in _start (line 61)  I mov'ed 'string' without the brackets for some reason the use of brackets is neccessary in the case of
> msg (line 84) ...why so?

For scasb to work, edi needs to be a pointer to the string, since the string isn't going to fit into edi.  The registers only hold numbers.  On line 84, you're moving the string onto the stack, and so you need [msg] which reads the four bytes pointed to by msg into edi, and not just msg which would load the pointer to the bytes into edi.

> also, the stack issue:
> based on my knowledge the stack grows downward but reads upward, i.e. if I push
> edi then I have pushed 4 bytes onto stack-and so sp decrements 4 times and points
> at last item pushed.  Sp only points to top of stack and knows nothing about memory below
> unless we tell it too by explicityly moving it down,which is allocating space basically,
> malloc() for the C gang. Am I getting it?

I think malloc runs off of the brk system call, but I don't know C.  Only ordinary variables in C are allocated on the stack.  If you're using a structure in a pointer to some malloc memory, you're not using the stack.  At least I'm pretty sure that's how it works.

Basically, in Linux (32-bit intel mode), the stack will always push dwords even if you push words or bytes.  After you push a value, ESP points to that value, such that after a 'push eax', [esp] == eax.  The bytes are stored in the same order as if you had done 'mov [esp], eax'.  In fact, a push is the same as 'sub esp, 4' and 'mov [esp], value' except that what ends up on the stack if you push esp seems to change with each processor version, sometimes it's the value before the push, other times it's the value after the push.

> My only concern is this:
> what does edi look like after line 84???
> we have 6 bytes going into a 4-byte register...
> my guess is:
> 6162630a with the CR and NULL being ignored.

Actually, it's 0x0A636261, you have to remember that byte order is reverse reading order.

> If I'm right then what does the stack look like after the push?

Stack: 0x61, 0x62, 0x63, 0x0A, argument list array, dword 0, environment variable array, dword 0, null terminated arguments and environment variables, and that's it I believe except there's probably some alignment bytes tossed in there somewhere.

> From what I see the values in the registers are pushed from the low-byte up to high so
> that 61 is on top of stack, or worded differently, esp holds the address of where 61 is.

Yep, that's right...

> line 17:           jmp chk_edi

Should this have been a call?  I can't figure out how the scan function gets called otherwise.

Anyway, let me paraphrase how to find the length of a null terminated string.  (untested code warning)  Those string instructions are tricky to learn.

	cld
	xor eax, eax
	mov edi, string_pointer
	mov ecx, any_value_sure_to_be_larger_than_the_string
	repnz scasb
	sub edi, string_pointer
	dec edi ; unless you want to count the null byte in the length

That ought to do it, length will be edi.  Zero length strings are fine, as long as the null byte is at the end.  Basically, "repnz scasb" will compare the byte at [edi] to al, and if they're not equal it will loop.  Regardless of wether it continues to loop or not, it'll also increment edi and decrement ecx, and if ecx is zero, it'll stop looping as well.  So, if say the first byte is a letter, and the second is zero, at the end it'll have added 2 to edi.  Then we subtract edi's original value, so we're left with the 2.  Subtract 1 for the zero byte at the end (the one that matched al) and you have 1, the length of the string.  It works with null strings as well, since the first byte matches, edi has 1 added to it, and that 1 is decremented at the end.

I know what you mean about those assembly language books.  They try to teach assembly like it's a language, when it's not (despite the "assembly language" name), and so they actually end up teaching how to use one particular assembler (which is really what you would want to call a language) with one particular operating system, and usually just do a lot of "here's how you do it" stuff and not enough "here's how this works" type stuff.

GRUB sample kernel question

[ram]

Hi,

I was looking at the toy kernel in the grub distribution (multiboot.h, 
kernel.c, boot.S
in the 'docs' subdirectory) and noticed boot.S starts out like this:

    .globl    start, _start
start:
_start:
    jmp    multiboot_entry
    ....
multiboot_entry:

I'm wondering why this jump is needed; couldn't the start/_start labels 
simply have
been placed adjacent to the multiboot_entry label thereby avoiding the 
jump ?

Thanks.

Ram

Re: GRUB sample kernel question

[Alexander Jänicke]

Am Samstag, 1. November 2003 18:07 schrieb ram:
> Hi,
>
> I was looking at the toy kernel in the grub distribution (multiboot.h,
> kernel.c, boot.S
> in the 'docs' subdirectory) and noticed boot.S starts out like this:
>
>     .globl    start, _start
> start:
> _start:
>     jmp    multiboot_entry
>     ....
> multiboot_entry:
>
> I'm wondering why this jump is needed; couldn't the start/_start labels
> simply have
> been placed adjacent to the multiboot_entry label thereby avoiding the
> jump ?
>
> Thanks.
>
> Ram


No, this jump is necessary for making sure that the cs register is initialised 
correctly. Every BIOS loads the bootloader to physical address 0x07c00. 
Normally cs=0 and ip=0x7c00, but to be on the safe side, you should make a 
far-jump. That's why code in most bootloaders begins with a 
jmp 0x0000:StartAddr or jmp 0x07c0:StartAddr, dependent on whether the 
location counter started at 0x0000 or 0x07c0.
If you are interested in os development, have a look at 
http://www.nondot.org/sabre/os/articles

Alex

Re: GRUB sample kernel question

[ram]

Alexander Jänicke wrote:

>Am Samstag, 1. November 2003 18:07 schrieb ram:
>  
>
>>Hi,
>>
>>I was looking at the toy kernel in the grub distribution (multiboot.h,
>>kernel.c, boot.S
>>in the 'docs' subdirectory) and noticed boot.S starts out like this:
>>
>>    .globl    start, _start
>>start:
>>_start:
>>    jmp    multiboot_entry
>>    ....
>>multiboot_entry:
>>
>>I'm wondering why this jump is needed; couldn't the start/_start labels
>>simply have
>>been placed adjacent to the multiboot_entry label thereby avoiding the
>>jump ?
>>
>>Thanks.
>>
>>Ram
>>    
>>
>
>
>No, this jump is necessary for making sure that the cs register is initialised 
>correctly. Every BIOS loads the bootloader to physical address 0x07c00. 
>Normally cs=0 and ip=0x7c00, but to be on the safe side, you should make a 
>far-jump. That's why code in most bootloaders begins with a 
>jmp 0x0000:StartAddr or jmp 0x07c0:StartAddr, dependent on whether the 
>location counter started at 0x0000 or 0x07c0.
>If you are interested in os development, have a look at 
>http://www.nondot.org/sabre/os/articles
>
>Alex
>-
>To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>
Thanks for the response but I'm still a little confused: my impression 
is that this
code is not a bootloader but a sample 32-bit OS loaded by GRUB, so GRUB has
already switched to protected mode when this code starts to execute ?

Ram

-
To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: confused asm newbie

[b klein]

hello.
I hope you dont mind me shortening up a little
--- Philip Jacob Smith <pj@evobsyniva.com> wrote:
.
.
.
> I know what you mean about those assembly language
> books.  They try to teach assembly like it's a
> language, when it's not (despite the "assembly
> language" name), and so they actually end up
> teaching how to use one particular assembler (which
> is really what you would want to call a language)
> with one particular operating system, and usually
> just do a lot of "here's how you do it" stuff and
> not enough "here's how this works" type stuff.
> 
.
.
im trying to learn asm and use nasm, ald and a little
gdb for it. im not a newbie to programming or
assembly. ive learned it some time ago and come back
to it now. so my question is what is the important
bits that are worth learning? Im not interested in
learning a tool, i want to learn the .. well
'language'
but if it isnt a language, what should it be?
addressing modes, big-little endian, memory models,
8-16-32-64 (12?) bits processors, ports, interupts or
something else?
 


this is my first post, i hope it isnt too bad.


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: confused asm newbie

[Frederic Marmond]

b klein wrote:

>im trying to learn asm and use nasm, ald and a little
>gdb for it. im not a newbie to programming or
>assembly. ive learned it some time ago and come back
>to it now. so my question is what is the important
>bits that are worth learning? Im not interested in
>learning a tool, i want to learn the .. well
>'language'
>but if it isnt a language, what should it be?
>addressing modes, big-little endian, memory models,
>8-16-32-64 (12?) bits processors, ports, interupts or
>something else?
> 
>  
>
Hum...
1: find something to do!
Take something you would like to do (an assembly routine that write a 
text to the screen very quickly, a boot loader (not so hard to do!), a 
ACPI state reader, or what else you want)

2: get a compilator (cc is one)

3: try to do it.

I Think it is the only good way to learn assembly. By this method, 
you'll see how to use a tool (the compilator, but it will not be the 
main goal, you can choose the one you want), learn how to get doc (about 
the OS you are on, about BIOS if you have no OS, about the chips if you 
don't want to use BIOS, ...) and how all that work.
Once you have enough knowledge about one particular architecture, you 
can safety try an other!

Fred

Re: confused asm newbie

[b klein]

--- Frederic Marmond <fmarmond@eprocess.fr> wrote:
> b klein wrote:
> 
> >im trying to learn asm and use nasm, ald and a
> little
> >gdb for it. im not a newbie to programming or
> >assembly. ive learned it some time ago and come
> back
> >to it now. so my question is what is the important
> >bits that are worth learning? Im not interested in
> >learning a tool, i want to learn the .. well
> >'language'
> >but if it isnt a language, what should it be?
> >addressing modes, big-little endian, memory models,
> >8-16-32-64 (12?) bits processors, ports, interupts
> or
> >something else?
> > 
> >  
> >
> Hum...
> 1: find something to do!
> Take something you would like to do (an assembly
> routine that write a 
> text to the screen very quickly, a boot loader (not
> so hard to do!), a 
> ACPI state reader, or what else you want)
> 
> 2: get a compilator (cc is one)
> 
> 3: try to do it.
> 
> I Think it is the only good way to learn assembly.
> By this method, 
> you'll see how to use a tool (the compilator, but it
> will not be the 
> main goal, you can choose the one you want), learn
> how to get doc (about 
> the OS you are on, about BIOS if you have no OS,
> about the chips if you 
> don't want to use BIOS, ...) and how all that work.
> Once you have enough knowledge about one particular
> architecture, you 
> can safety try an other!
> 
> Fred
> 
thanks for your reply.
Im doing something like that:
started with trying to do a FFT butterfly using the
fpu unit. i use the fpu because i want to learn how to
use it,the school's asm did not include that bit.
so far i got to:
flotingpoint variables A,B
A=A+B
B=A-B
now its just some cos and sin with the fpu.
thats cool.

The problem is how its connected to the essence of
assembly and what this essence is, because i did the
same with c++ (dont know how it goes with the
registers though).
using asm i learnd about the scratch regs,fpu and some
memory mgmnt. and i think that is the important bit
concerning asm. i allso learned a bit about nasm
commands and how to use ald (gdb is a headache). But
is is as important as the fpu and regs? 
assembly is good for some things, OS, hardware
programming, dsp, etc. i think it isnt practical to
write a databese in assembly only(possible yes). so
whats worth concetrating on ?
thanks
benny   




__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Re: confused asm newbie

[Frederic Marmond]

I don't really see what you want...
If it is for:
- asking some question about assembly
- assembly with linux
- or even low level linux
it is the good place, but please, ask more precise question.

If you want just to discuss about: "what is assembly, what for, and what 
god has to do with this", i'm afraid you'll don't have much answers... ;)

And please, remember that:
There are 10 types of people: those who understand binary language, and 
the others.
;-)

Fred

b klein wrote:

>--- Frederic Marmond <fmarmond@eprocess.fr> wrote:
>  
>
>>b klein wrote:
>>
>>    
>>
>>>im trying to learn asm and use nasm, ald and a
>>>      
>>>
>>little
>>    
>>
>>>gdb for it. im not a newbie to programming or
>>>assembly. ive learned it some time ago and come
>>>      
>>>
>>back
>>    
>>
>>>to it now. so my question is what is the important
>>>bits that are worth learning? Im not interested in
>>>learning a tool, i want to learn the .. well
>>>'language'
>>>but if it isnt a language, what should it be?
>>>addressing modes, big-little endian, memory models,
>>>8-16-32-64 (12?) bits processors, ports, interupts
>>>      
>>>
>>or
>>    
>>
>>>something else?
>>>
>>> 
>>>
>>>      
>>>
>>Hum...
>>1: find something to do!
>>Take something you would like to do (an assembly
>>routine that write a 
>>text to the screen very quickly, a boot loader (not
>>so hard to do!), a 
>>ACPI state reader, or what else you want)
>>
>>2: get a compilator (cc is one)
>>
>>3: try to do it.
>>
>>I Think it is the only good way to learn assembly.
>>By this method, 
>>you'll see how to use a tool (the compilator, but it
>>will not be the 
>>main goal, you can choose the one you want), learn
>>how to get doc (about 
>>the OS you are on, about BIOS if you have no OS,
>>about the chips if you 
>>don't want to use BIOS, ...) and how all that work.
>>Once you have enough knowledge about one particular
>>architecture, you 
>>can safety try an other!
>>
>>Fred
>>
>>    
>>
>thanks for your reply.
>Im doing something like that:
>started with trying to do a FFT butterfly using the
>fpu unit. i use the fpu because i want to learn how to
>use it,the school's asm did not include that bit.
>so far i got to:
>flotingpoint variables A,B
>A=A+B
>B=A-B
>now its just some cos and sin with the fpu.
>thats cool.
>
>The problem is how its connected to the essence of
>assembly and what this essence is, because i did the
>same with c++ (dont know how it goes with the
>registers though).
>using asm i learnd about the scratch regs,fpu and some
>memory mgmnt. and i think that is the important bit
>concerning asm. i allso learned a bit about nasm
>commands and how to use ald (gdb is a headache). But
>is is as important as the fpu and regs? 
>assembly is good for some things, OS, hardware
>programming, dsp, etc. i think it isnt practical to
>write a databese in assembly only(possible yes). so
>whats worth concetrating on ?
>thanks
>benny   
>
>
>
>
>__________________________________
>Do you Yahoo!?
>Protect your identity with Yahoo! Mail AddressGuard
>http://antispam.yahoo.com/whatsnewfree
>-
>To unsubscribe from this list: send the line "unsubscribe linux-assembly" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>  
>

Re: confused asm newbie

[Philip Jacob Smith]

>> I know what you mean about those assembly language
>> books.  They try to teach assembly like it's a
>> language, when it's not (despite the "assembly
>> language" name), and so they actually end up
>> teaching how to use one particular assembler (which
>> is really what you would want to call a language)
>> with one particular operating system, and usually
>> just do a lot of "here's how you do it" stuff and
>> not enough "here's how this works" type stuff.

To expand on this, I think there are four areas to assembly language:  the instruction set itself, the operating system, the hardware, and the assembler.

Every book I've read had an instruction set reference which gave brief descriptions of the instructions.  However, I think these should include a bit more than they usually do.  Like the description for the add instruction should explain how it manages to work correctly on both signed and unsigned numbers.  The jump instructions should explain that jb/ja are for use with unsigned numbers and jg/jl are for signed numbers.  Yet every time I see such a listing, it just says "jumps on the condition that the such and such flags are set."  I don't even know what flags they are, because that isn't really important.  What's important is what the instruction is useful for, and the jg instruction is useful for jumping on the condition that the previous add, sub, or cmp instruction resulted in a number between 1 and 127 (for bytes, that is, and I can't say that I know that is correct, but rather that's just what I always use it for, rather than check for overflow errors I always just m!
 
 ake 
sure they won't occour in the first place).  Telling me what flags it sets doesn't really tell me anything.

Every book I've read deals with just one operating system.  I don't think this is bad, I couldn't honestly expect anything else.  What bothers me is that they both claim to be about general assembly langauge (I never saw a book titled "DOS Assembly Language", always just "Assembly Language") and yet concentrate heavily on how to get things done under their one specific operating system.  95% of what someone reads in a DOS assembly langauge book is going to be useless for someone in Linux, and so I think it's rather deceptive to claim that the book is about assembly langauge when mostly it isn't.  My other complaint here is that pretty much every book is like this.  They'll spend 90% of the book explaining how to use every DOS interrupt imaginable, yet they can't squeeze in important things like how to use the SCASB/CMPSB instructions, which leads to people brewing up their own wickedly horrible functions that try to do the same things.  Some books don't even bother with simp!
 
 le ones 
like LODSB/STOSB.

Most books I've read don't deal with hardware much at all.  It's interrupt this and interrupt that.  Now hardware programming is difficult, but it's exactly that reason that it needs to be in a book.  The books I have seen it in did quite poorly.  I read one book that had a section on VGA and even an example on using 640x480 16-color mode, and although the example worked, the textual explanation was so lacking I had no idea how they did it.  I could have just copied their code and had something that worked, but that's not why I bought the book.  I bought the book so I could learn to do this stuff myself, and just using someone else's code isn't learning.  While I'm on this topic, I'll recommend "The Indispensable PC Hardware Book."  This is the only programming book I've ever bought that I've kept.  All others have either been given away, or if they were really bad, went into the trash.

Every book I've read treats the assembler as if it is assembly language.  In my opinion it's just the opcodes that are assembly language, all of the directives and the general syntax of the assember are something else.  Books tend not to make any distinction between the two.  The result is that people read a book on MASM, then switch to NASM, and wonder why NASM doesn't have "assume", "word ptr", or why code like "mov eax, data[14]" causes errors, and in particular wonder why "mov eax, data" doesn't do what they expect.  I've seen people say that the opcodes are "machine langauge" and that the mnemonics are "assembly langauge" but that's just silly.  The opcodes are the langauge, it's just that all those numbers are hard to remember so we gave them little names, known as mnemonics.  Most assemblers use the same mnemonics, and differ slightly on their syntax for operands.  A good assembly book would explain this, and would draw a good line between instructions and directives !
 
 so that 
people understand what gets turned into code and what's there just to help the assembler out.  Most importantly, it should be understood that the assembler is a tool, not a programming language.  The assembler translates our mnemonics for us, and also allows us to use labels instead of hard coded addresses which would be hard to work with.

In general, I got into assembly language because I wanted to deal with all the little details and the hard stuff, and assembly books all try to generalize as much as possible and make things as easy as possible, the end result being that I was always disappointed.  It's as if they didn't actually want to teach me anything, but rather get me to the point where I could write _something_ that worked, at which point they could declare their job complete.  That's not what I like to spend my money on.

  

Re: confused asm newbie

[b klein]

thank you for your answers, philip and fred.
they were both insightful and practical.

--- Philip Jacob Smith <pj@evobsyniva.com> wrote:
> >> I know what you mean about those assembly
> language
> >> books.  They try to teach assembly like it's a
> >> language, when it's not (despite the "assembly
> >> language" name), and so they actually end up
> >> teaching how to use one particular assembler
> (which
> >> is really what you would want to call a language)
> >> with one particular operating system, and usually
> >> just do a lot of "here's how you do it" stuff and
> >> not enough "here's how this works" type stuff.
> 
> To expand on this, I think there are four areas to
> assembly language:  the instruction set itself, the
> operating system, the hardware, and the assembler.
> 
> Every book I've read had an instruction set
> reference which gave brief descriptions of the
> instructions.  However, I think these should include
> a bit more than they usually do.  Like the
> description for the add instruction should explain
> how it manages to work correctly on both signed and
> unsigned numbers.  The jump instructions should
> explain that jb/ja are for use with unsigned numbers
> and jg/jl are for signed numbers.  Yet every time I
> see such a listing, it just says "jumps on the
> condition that the such and such flags are set."  I
> don't even know what flags they are, because that
> isn't really important.  What's important is what
> the instruction is useful for, and the jg
> instruction is useful for jumping on the condition
> that the previous add, sub, or cmp instruction
> resulted in a number between 1 and 127 (for bytes,
> that is, and I can't say that I know that is
> correct, but rather that's just what I always use it
> for, rather than check for overflow errors I always
> just m!
>  ake 
> sure they won't occour in the first place).  Telling
> me what flags it sets doesn't really tell me
> anything.
> 
> Every book I've read deals with just one operating
> system.  I don't think this is bad, I couldn't
> honestly expect anything else.  What bothers me is
> that they both claim to be about general assembly
> langauge (I never saw a book titled "DOS Assembly
> Language", always just "Assembly Language") and yet
> concentrate heavily on how to get things done under
> their one specific operating system.  95% of what
> someone reads in a DOS assembly langauge book is
> going to be useless for someone in Linux, and so I
> think it's rather deceptive to claim that the book
> is about assembly langauge when mostly it isn't.  My
> other complaint here is that pretty much every book
> is like this.  They'll spend 90% of the book
> explaining how to use every DOS interrupt
> imaginable, yet they can't squeeze in important
> things like how to use the SCASB/CMPSB instructions,
> which leads to people brewing up their own wickedly
> horrible functions that try to do the same things. 
> Some books don't even bother with simp!
>  le ones 
> like LODSB/STOSB.
> 
> Most books I've read don't deal with hardware much
> at all.  It's interrupt this and interrupt that. 
> Now hardware programming is difficult, but it's
> exactly that reason that it needs to be in a book. 
> The books I have seen it in did quite poorly.  I
> read one book that had a section on VGA and even an
> example on using 640x480 16-color mode, and although
> the example worked, the textual explanation was so
> lacking I had no idea how they did it.  I could have
> just copied their code and had something that
> worked, but that's not why I bought the book.  I
> bought the book so I could learn to do this stuff
> myself, and just using someone else's code isn't
> learning.  While I'm on this topic, I'll recommend
> "The Indispensable PC Hardware Book."  This is the
> only programming book I've ever bought that I've
> kept.  All others have either been given away, or if
> they were really bad, went into the trash.
> 
> Every book I've read treats the assembler as if it
> is assembly language.  In my opinion it's just the
> opcodes that are assembly language, all of the
> directives and the general syntax of the assember
> are something else.  Books tend not to make any
> distinction between the two.  The result is that
> people read a book on MASM, then switch to NASM, and
> wonder why NASM doesn't have "assume", "word ptr",
> or why code like "mov eax, data[14]" causes errors,
> and in particular wonder why "mov eax, data" doesn't
> do what they expect.  I've seen people say that the
> opcodes are "machine langauge" and that the
> mnemonics are "assembly langauge" but that's just
> silly.  The opcodes are the langauge, it's just that
> all those numbers are hard to remember so we gave
> them little names, known as mnemonics.  Most
> assemblers use the same mnemonics, and differ
> slightly on their syntax for operands.  A good
> assembly book would explain this, and would draw a
> good line between instructions and directives !
>  so that 
> people understand what gets turned into code and
> what's there just to help the assembler out.  Most
> importantly, it should be understood that the
> assembler is a tool, not a programming language. 
> The assembler translates our mnemonics for us, and
> also allows us to use labels instead of hard coded
> addresses which would be hard to work with.
> 
> In general, I got into assembly language because I
> wanted to deal with all the little details and the
> hard stuff, and assembly books all try to generalize
> as much as possible and make things as easy as
> possible, the end result being that I was always
> disappointed.  It's as if they didn't actually want
> to teach me anything, but rather get me to the point
> where I could write _something_ that worked, at
> which point they could declare their job complete. 
> That's not what I like to spend my money on.
> 
>   
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-assembly" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
http://vger.kernel.org/majordomo-info.html


__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
http://companion.yahoo.com/