Re: A patch for linux 2.1.127

Robert L Krawitz (rlk@tiac.net)
Wed, 11 Nov 1998 14:49:51 -0500

> From: alan@lxorguk.ukuu.org.uk (Alan Cox)
> Date: Wed, 11 Nov 1998 12:02:41 +0000 (GMT)
>
> > 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

I think there's some talking at cross purposes going on here, but there are
valid points on both sides.

It's certainly true that Unix assemblers have traditionally been very bare
bones with a standardized syntax. That's 'cuz we Unix geeks like to write
everything, including the kernel, in C, and our C compilers have traditionally
been designed to retarget to other platforms easily. So having very different
assembly formats for different platforms simply gets in the way of compiler
writers (and the rest of the tool chain, for that matter), without helping
system programmers very much.

Device drivers are frequently written entirely in C, even to the level of
frobbing device registers. Hell, even programmed I/O is often written in C.
I've done it, and gotten 90-95% of hand coded assembler performance (even
though my code had to do a bit more). That's not to denigrate Richard, merely
to point out that that's where we're coming from.

On the flip side, a lot of device drivers for PC hardware (in particular) has
been developed in x86 assembler using the Intel assembler. It's certainly
reasonable that these folks don't want to have to reinvent the wheel, and the
fact that I wrote a programmed I/O routine in C doesn't mean that everyone
else either wants to or can do so without losing gobs of performance.

It also seems pointless for everyone to write their own macro preprocessor and
translator from Intel to Unix syntax. Nor does it make much obvious sense to
write a whole new assembler from the ground up. Has anyone written a
translator between Intel format (including the macro processor) and gas
format?

-- 
Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/


Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net


"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton


-
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/