GC

[spc@gate.net]

On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
>
> >   Well, not to put a too find point on it, I ran the following C code
> > through 'gcc -S':
>
>    By default, gcc does not provide a readable output,
> but one that is small and assembles faster.

  I don't buy that argument.  Sure, a smaller file will take a smaller amount
of time to assemble, but at what expense?  Human comprehension?  There are
people out there that understand, for example, the configuration file for
sendmail.  Sure, it's easy for sendmail to parse.  Heck, the parser was
probably written in an hour or two.  Sure reads sendmail.cf quickly.

  Have you, Fare, personally, ever tried writing a sendmail.cf file?  Or
modify an existing one?  I have.  It's not pretty.

  Now, what does this have to do with the HLL/LLL?  Well, I place readability
high up on the list, no matter what the level.	To sacrafice readability for
the false gods of speed and size (of source code!  Geeze!) is stupid, IMHO.

> Anyway, the asm output by GCC is definitely not meant to be used
> as the basis for asm development anyway: modifications are more
> consistently made inside the C source, with inline asm if needed.

  Obviously one wouldn't use GAS as a production assembler.  Even the
assembler on my Color Computer (EDTASM) was much better than GAS.  And yes, if
you are working on C code, it's more effective to wrought changes in the C
code.

  As far as inline assembly, I find that extreamly heretical and don't do it
myself.  One reason is that it's not portable at all (even across compilers
under the same OS on the same architecture), so if you resort to Assembly, why
not put it in its own file?  Secondly, even poorly written Assembly code (in a
separate assembly file) tends (more often than not, thankfully) over commented
so if one does need to reconstruct a HLL replacement for the code, it's
easier.  About inline assembly?  I've hardly ever seen it commented.

  And I've been burned by the practice of inline assembly.  At one company (I
left due to their C coding standards, BTW) there was one "C" function which
basically was:

sometype somefunctionname(type yada, type yada, type yadayada, that is)
{
  somemore vardecls;
  someother otherdecls;

  asm { 	/* whatever the magical incantation was */
	/* lines and lines of uncommented inline assembly */
  }

  vardecls=otherdecls;
  somerandomCcode();
  somemoreCcode();

  asm {
	/* gobs more lines of uncommented inline assembly */
  }

  return (sometypevar);
}

  No ifdefs.  Just raw inline assembly, which wasn't commented because of the
companies policies towards C (whereas their standard for assembly code (in
.asm files) was completely different.  Go figure).

  And you're saying it's easier to work with?  Yea, my job was to port this
mess (originally an MS-DOS application) to Unix.  Sorry, to SunOS, Solaris,
Linux, IRIX, BSD, SYSV, etc etc.  The assembly code may have been required
when their product had to run under 286s.  Not anymore.

  And it being inline didn't help matters, since the "original C code" was
long gone.

> If you modify the asm, you can't modify the C source later,
> or you'll clobber the asm.

  So?  If you stick in inline assembly, you're in the same boat more or less.

>    Asm output is meant so we understand and debug/verify,
> so that we modify the C sources and C compiler options,
> or possibly find a compiler bug.

  Take a double look at the output from the AIX version.  I'd be hardpressed
to verify the output of that mess.

>    BTW, GCC has option -fverbose-asm for a more readable output.
> The output from the following command was quite clear to me (not included).
> gcc -bi486-linuxaout -S -fomit-frame-pointer -O2 -m386 -fverbose-asm hello.c
>
  Yes, I tried that.  Funny thing was, not only was it a bit more readable,
but smaller as well.  Still doesn't follow my conventions though 8-)

>    However, any discussion about gcc should not go on this list.
> If you want to continue, please do it by private mail.
>
  Well, I'll step off my GCC soapbox now ...

> >[your version]
> >   Certainly a lot more readable than the mess GCC outputs, and certainly not
> > harder to output either.
>    Certainly not as readable, maintainable, and portable
> as the C program statement, and less efficient than what GCC gave me.
>
  While it certainly wasn't portable, I take offense to the unreadable and
non-maintainable charge.  Even compared to C.  And yes, I do know what I wrote
wasn't the most efficient code, but I was using what GCC spit out at me.

> > Gee, I have all this 386 code, but it's in Intel
> > format, not the ghastly GCC/AT&T syntax.
>    Who cares if the compiler->assembler interface
> is in Intel or AT&T syntax ?

  The poor schmuck who has to get his assembly code (in Intel format) to run
on a 386 based system that uses AT&T syntax, for one.  Me.  Some other people
I know.

  Someone who has the reference manual for the CPU from the manufacturer and
is trying to do a port of some system where Some Assembly is Required.	The
last thing needed at that point is a pointless change in syntax.

  Granted, if I'm not ever going to USE assembly, it doesn't matter.  But if
I'm ever in a situation where I do, then I care.

> Actually, lots of folks do prefer the AT&T syntax.
> And I would prefer the interface to be done directly with
> an appropriate binary format.
>
  By this, do you mean HLL->binary sludge (executable, etc)?  If that's the
case, then why all the mess with the LLL?

> >   -spc (And the worst assemblers I've used have been on Unix systems ... )
>    Because once you have a stable system, and know you'll use it for long,
> the $$$ spent in assembling and debugging asm,
> are better spent in buying faster hardware and writing better compilers.

  I'm not really arguing that point with you.  I am, however, arguing the
point that it's okay to leave such tools in a primitive state, saying "that
the HLL will take care of those details for you."  You don't even HAVE a HLL,
much less a LLL defined at this point.	And saying "Don't bother building
powerful tools at such a low level.  It's pointless" is stupid.  It benefits
all to have powerful tools at all levels.

> Under Linux, even device drivers are done in C
> (with a few inline asm macros).
> And it is much faster and more reliable than any asm-written DOS version.
>
  It may be faster to develop, but they're no less reliable than the asm
written DOS versions.  And while the Linux drivers were written in C, they're
so convoluted because "Oh, well, GCC produces better code if I write it this
way."  I mean, if they're THAT concerned about the code produced, why not
write in Assembly in the first place?  And won't the code break when a new
release of the compiler is made?  Or does the compiler have to maintain
backward compatibility with previous code generators it may have used?

  Blah.

>    Low-level programming should not be done in asm,
> but in a low-level language like C or FORTH,

  Uh, Fare, there are some things you just CAN'T DO in anything other than
Assembly.  Assembly is far from dead.  Hidden, yes.  Dead, no.

  -spc (And I'm not saying that everything has to be done in Assembly
	either ... just don't forsake the low level for the high ... )