> To: Rafal Boni <rafal@mediaone.net>
>
> Rafal Boni <rafal@mediaone.net> writes:
>
> > -> Specifically, named struct field initializers, for example,
> > -> 
> > -> static struct wsscreen_descr wssd_stdscreen = {
> > -> 	name: "LCD",
>
> [...]
>
> > IMNSHO, the structure definition should serve as adequate
> > documentation for the fields in the structure, even if it's located
> > in a header file somewhat removed from the declaration.
>
> It's not just documentation, it's like named parameter passing in
> e.g. Ada. The point is that you don't have to remember the exact order
> of fields in a struct and lets people reorder them for cache whatnot
> behaviour.

It is completely agreed that the extensions are usually nice and convenient
things to have. Some of them do increase the level of abstraction provided
by constructs in which they are employed. I like Ada named parameters.

It is _still_ professional to avoid them, for reasons I have previously
written at length regarding. Usually, if you really need that abstraction,
it is also available in __STDC__ macros. Hardly anyone wraps initializers
and calls, though, so it must not be considered a necessary abstraction.

> Of course if NetBSD does not explicitly depend on gcc, the syntax have
> to go, which is a shame, because I think it looks quite pretty :-)

I suspect we all agree with this, at least, I do. The extensions are
nice. But don't use them. :-)

> If gcc is not official, how do you do stuff like this specific
> example, taken out of my code for the Psion 5 MX port:
>
> u_int32_t
> inline static mmu710T_get_ctrl(void)
> {
> 	u_int32_t c1;
> 	
> 	__asm __volatile("mrc	p15, 0, %0, c1, c0"
> 	    :"=r"(c1))
> 	    ;
> 	return c1;
> }
>
> making use of the cool gcc asm syntax?

Actually, this one example could be easily done with a plain, old-style
asm(), which would at least use a more universal extension.  Sadly, the
gcc docs discourage this, and even imply that such statements won't work
because the compiler will eat your return values. (Although in fact I don't
think it does.)

> (The alternative, it seems to me, is to study ABI documents to decide
> which registers may be clobbered which is not my idea of fun and
> creates unmaintainable assumptions).

Oh come on, you can't do any serious work without knowing the ABI. It's
almost always portable between all compilers for a machine, and you absorb
the ABI about for free when learning the machine language.

But I will freely admit that the GNU asm() statement is the most useful of
the extensions, and since it provides a functional benefit a reasonable
argument can be made for using it at those times that a locore.s (a real)
subroutine would be too slow. (But slow only matters if the code is on a
frequently used path.  Less than 10% of a program's lines are.)

There is no reason to go to extremes either way. If, all things considered,
the positives outweigh the negatives, by all means use a gnu asm(). Just
make sure you know the negatives. And don't use zillions of them. Linux
did that, its kernels are now tied to specific gcc releases, and the code
sometimes has an unprofessional look. It is not even maintained in a source
code control system, which tends to confirm the diagnosis of "unprofessional".

And the fact that use of gnu asm() can be justified at times does not
speak one way or the other about the rest of the extensions.

// ross