Messages in this thread | | | Date | Wed, 11 Nov 1998 09:19:15 -0500 (EST) | From | Alexander Viro <> | Subject | Re: A patch for linux 2.1.127 |
| |
On Tue, 10 Nov 1998, Richard B. Johnson wrote:
> Because I'll be damned if I'll let perfectly correct Intel assembly- > language code get mangled to: > > xxx.asm: Assembler messages: > xxx.asm:6: Error: operands given don't match any known 386 instruction > xxx.asm:9: Error: Ignoring junk '[bp-10]' after expression ^^^^^^^^ %bp(-10)
> xxx.asm:9: Error: operands given don't match any known 386 instruction > > ... by an assembler that doesn't know Intel Assembly, but pretends so.
It's an assembly for Intel processors conforming to normal conventions, used pretty much everywhere except Intel. Intel assembly != assembly for Intel.
> It is thoretically possible to convert correct code to GNU `as` junk, > however, the damn thing doesn't even do MACROs so if I am going to > make: > adc eax, [ebx+1000] > adc eax, [ebx+996] > adc eax, [ebx+992]
It uses C preprocessor. Or you can pass the input through m4 or any other macro-language of your choice.
> ... etc.. a thousand times I would certainly ^^^^^^^^ ITYM 250 ;-) > want to use another tool. It also doesn't know how to write > a byte to a memory location, i.e., it doesn't know about the PTR Yes it does. > expression to tell it whether to write a byte, a word, or a longword So tell it in the last character of operator. > to a memory location when you do something like: > > mov variable,0 movb $0, variable
> That's why we have BYTE PTR, WORD PTR, DWORD PTR, etc. Otherwise a > zero could (and does) smash adjacent data. It's a very bad tool.
Erm... What about _learning_ it?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |