>I think the bottom line is that gcc inline asms are more powerful in
>one aspect than other schemes, and in another aspect they are less
>powerful than such schemes. It was a trade off in design when they
>were initially implemented. Perhaps it's showing it's age now, so
>lets work on fixing it.
>
>Later,
>David S. Miller
>davem@dm.cobaltmicro.com
>
>From: alan@lxorguk.ukuu.org.uk (Alan Cox)
>Date: Wed, 11 Nov 1998 12:02:41 +0000 (GMT)
>Subject: Re: A patch for linux 2.1.127
>
>> 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
>
>Of course it doesn't do macros, this is unix. There's a perfectly good
>set of preprocessors that do macros, why should gnu as be another one to
>have its own different magical interpreter
>
>> 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
>> expression to tell it whether to write a byte, a word, or a longword
>> to a memory location when you do something like:
>
>of course it does - movb, movw, movl, and furthermore because it follows
>a cross platform standard I can read non x86 stuff easily. It took me about
>3 days to get the hang of gnu assembler while writing the original linux/smp
>boot code
>
>Alan
>
Could the original poster elaborate on what breaks if you rename
your canonical Intel assembler, or your GForth vocabulary implementing
a post-fix assembler with Forth as macros, to as or as86?
Early on in the as docs it is stated that as is primarily a
sub-util of gcc, so I would guess replacing it is not a hard fight,
unlike, say, adding a machine description to gcc for a stack machine.
Rick Hohensee http://cqi.com/^humbubba cLIeNUX xart kandinski
and maybe H3sm in this lifetime.
-
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/