| |
| |
| |
|
Page: 1 2
Comments:
<0> WHY did intel make their stack grown DOWN?
<1> because they wanted to ?
<2> because when you have only 64k it's easier maybe ?
<1> why easier?
<2> because you may have the max of code and stack
<0> edcba: but code is a fixed size
<2> or not :)
<0> edcba: process's stack may change size but code does not right?
<2> but it's easier since you always put sp at top of memory
<2> and you don't care about your code size
<1> seb-; so what's the answer ?:o
<2> memory size don't change as often as code size :)
<0> scarry: what's the question?
<1> < seb-> WHY did intel make their stack grown DOWN?
<0> edcba: ok, i think you made a good point
<2> but i don't really know if it is the awnser
<0> scarry: because easy to make base of stack be at top of memory!
<2> i never dealt with 8086 8088
<3> stack grown down and heap grown up
<0> scarry: s/base/top
<1> hmm yeah but basically you can look @ it reversly
<3> this to avoid overwriting
<1> what do you mean ?
<0> hkj2: explain please
<2> if they were expanding in the same direction you would have some problems
<2> you'll have to define a size for the stack
<2> and you could overwrite when either the heap or the stack goes out of memory
<2> if they grow in inverse direction they overwrite only when there is no more memory
<3> all right
<3> :)
<2> but i wonder if the heap mechanism were in the design decision
<3> yes, they are dinamic space address, so it's necessary use this mechanism
<2> but at time of 8086 are programmers were already using heaps ?
<3> mmh... i don't know
<4> I am looking for a good ARM asm reference somewhere in the neighborhood of 10 pages long. A list of mnemonics, their parameters, a short description, etc. The official 2-page quick reference has far too little information. The official 800-page reference has far too much information, and its poorly organized. Suggestions?
<0> every process has a /stack/ but what is the *purpose* of the 'heap'?
<2> dynamic allocation
<2> that are not local variables
<0> edcba: are there special ***embly instructions to dynamically allocate something?
<2> no
<0> edcba: then how can our poor ***embly code use the heap?
<2> you handle it yourself :)
<5> just like any other program?
<0> skuggi: but edcba said there are no instructions to say..."ok, use the heap now please!"
<2> if you have an instruction that only increments it doesn't mean you cant add 2 :)
<0> edcba: um, by that logic 2 local variables = a dynamic heap variable?
<0> edcba: ok, sorry leemie guess
<0> edcba: you 'jmp' to the heap and put values there? then 'jmp' back to your code?
<0> edcba: that would work!
<2> just google heap
<5> seb-: the heap is just a structured way to use pages allocated from the OS
<0> In general how does cpu access I/O devices?
<0> i understand fetch-execute cycle to access RAM....not sure if there is a generic recipe to access I/O devices
<6> doesnt certain memory access the pci bus?
<7> MUL kills EDX :(
<6> does it?
<6> oh yeah...
<6> anyone know anything about that new virtualization ****e?
<0> tecate: certain memory communicates w/ I/O devices?
<6> seb-: either u access i/o through opcodes or certain memory, and i thought it was certain memory, but u raised a good question that i forgot so im looking it up now :)
<0> tecate: thanks
<6> seb-, why do u ask?
<0> tecate: i going to teach a beginning cl*** on ***embly and wanted to say a few sentences about i/o devices
<6> u should keep copius documentation and put it on the web somewhere, preferably wikibooks or wikipedia :)
<6> i wood definately bee interested, as others im sure
<4> I am looking at some ARM asm that doesnt match the syntax I am used to. I see "123_11" and ";124_10" on lines by themselves, left aligned like a label might be. any ideas what those are?
<0> help! no errors when i link in libc function but when i try to run the linux-ELF executable shell says 'command not found' <-- only happens if i try to link in libc func
<8> show the command you're trying
<0> % nasm -f elf hello_world_stdlib.asm
<0> % ld hello_world_stdlib.o -lc
<0> % ./a.out
<0> ./a.out: Command not found.
<0> wcstok: notice nasm and ld give *no* errors!
<8> is there an a.out in the directory
<0> % ls a.out
<0> a.out
<8> ls -l a.out
<0> ls -l a.out
<0> -rwxr-xr-x 1 seb seb 1984 2006-07-29 23:15 a.out
<0> wcstok: perhaps objdump -x output would be revealing?
<8> maybe, also try file on it?
<0> wcstok: % file a.out
<0> a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
<0> wcstok: all my codes that *don't* call printf are fine
<8> try linking using gcc maybe?
<0> wcstok: that works
<0> wcstok: i wanted to be macho and use ld
<8> well, find out what gcc is doing and your ld commandline isnt
<8> my guess would be you aren't initializing the c library
<0> wcstok: 'initialize c library' ?
<8> gcc -v thefile.o -o a.out
<0> wcstok: here is objdump http://cpp.enisoc.com/pastebin/7395
<8> are you starting at _start or main
<0> wcstok: can you please look at gcc -v output with me?....http://cpp.enisoc.com/pastebin/7396 there is no obvious 'ld' line
<0> wcstok: the collect2 line works
<6> i am tecate
<8> $ cc test.c
<8> #pragma packed
<8> ........^
<8> C-I-UNKNOWNPRAGMA, The pragma "packed" is unrecognized.
<8> at line number 2 in file DKA0:[USERS.JWHITE]TEST.C;5
<8> blah, wrong paste
<8> jwhite: ~> nasm -felf test.s
<8> jwhite: ~> ld -lc /usr/lib/crtbegin.o /usr/lib/crt1.o test.o
<8> jwhite: ~> ./a.out
<8> 1234567jwhite: ~>
<8> \>
<6> /random reply
<0> wcstok: gcc -v gives a horrid huge linking line
<8> most of that mess is pulling in the c startup code and dynamic linking/etc
<8> /usr/bin/ld -V -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/X11R6/lib -L/usr/lib test.o -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crtn.o
<8> is what mine does
<0> wcstok: i'm teaching an intro to ***embly cl*** and wanted to avoid linking with gcc but it looks like ld's job is too complicated to use directly except in toy cases
<8> depends...you could stay away from things that depend on the c lib being setup (especially stdio), string functions should be ok, etc
<9> ouch, clib
<8> but since you insist on using the c lib, you have to play by its rules...
<0> wcstok: why can't c lib just be one little .so or .o file to link in?
<9> thats a no no question on #asm... /mode #asm +norules
<8> *shrug* ask the hippies who wrote it
<0> heh
<9> ftp://download.intel.com/technology/computing/vptech/C97063-002.pdf
<9> ouch. all of a sudden i dont think so much of software
<9> an os in hardware. jeeeeeeeeeeeeeeeese, did it have to take _that_ long
<0> wcstok: thanks for the help
<10> Hi
<11> Hello Cheery
<10> I gues osdev guys doesn't like if I talk too much about my ***embler programming there.
<11> Hum. Dunno. But it's never a bad idea to produce some traffic here =)
<10> I wonder if I'd get the answer to the 48bit and 64bit stuff I saw in IA-32 specs.
<10> how IA-32 is able to handle things like qwords and owords?
<10> (64bit and 128bit)
<11> ugh. not from me. I'd even say it's more osdev specific. :]
<11> oh
<11> yes. no problem, it just requires some more i/o accesses.
<10> does it get those things straight from memory?
<11> and the 128bit (and wider) types are just for the multimedia extensions, like mmx and s*** on x86
<11> Cheery, that depends on the hardware. The basic unit is 32bits for non-64bit processors. Accessing them requires multiple accesses.
<10> aah.
<11> Since the addressing is 32bit and is optimized for 32bit units.
<11> But that is for the general purpose part of the processor. Concerning the MM extension, I am not sure. Possibly they added a wider bus so you can efficiently load wider units.
<10> Maybe I should look into IA-64 too at some point, I remember that adds some new registers and other stuff, which already complicates the intel format more, so it is again damn more harder to encode than IA-32
<11> Cheery, yeah. You could try to find something in the intel optimization manual (vol4, iirc) about it.
<10> k.
<10> "Some SSE/SSE2 instructions use the immediate byte as a condition code." this is again one weird thing I found from sandpile.org
<10> what's a condition code?
<10> I'm happy I decided to build opcode solver which uses functions as data containers to create lookup structure.
<11> Cheery, the term is Predicated Execution. Instead of branching you have a little prefix that tells the IF stage of the pipeline if the instruction should be processed or skipped. Setting the prefix would skips some instructions, clearing it would read them. That's about the same as if you had a if/then/else but without jumping, which is good for keeping the pipline filled.
<11> I gotta go. Cu later maybe
<10> aah.
<10> kewl!
Return to
#asm
or
Go to some related
logs:
zsnes.deb
error installing tls module
ubuntu quod libet m4a
vesa-ng amd64
#asm
shadowpillar
#javascript
postfix email all
IO::Socket::INET read
freebsd subwoofer ich4
|
|