Thoughts on the C/Assembly Debate

In article <b1Jqi.83$jO3.8@nlpi070.nbdc.sbc.com>, <hel@40th.com> wrote:
>Check Intel's marketing for its C/C++ compiler.
>I'm sure in there somewhere is how it detects
>SOA/AOS requirements and reorders data, and
>vectors it all using SSE2/3/4 for best effect.
>I'm almost as sure that MS/VS will do the same.
>All this even without #pragma hints. Since so
>few will ever know asm well enough to beat a
>current compiler, guru code (potentially) being
>better than compiler code is pretty much moot.
>Besides, this is more about knowing how to order
>data, not a compiler/assembler thing. Had to yawn

One can easily give examples where the current languages
are poor, and one can produce better instruction sets. One
case, lacking in all computer languages to my knowledge
(LISP may be an exception, but it is too clumsy) is the
ability to have a list of results to the left of the
replacement operator; this utility of this cannot be
achieved by a struct. Also, there are many useful
procedures in many machines (alas, they are declining
due to the HLL mentality) which the HLLs cannot even
conceive of.

The assembly languages can be improved as well, decreasing
their code length to be comparable to that of HLLs. The
point is to use short names to avoid errors, and one can
even use overloading in the assembler. There is no need
to assume that assemblers have to be complete idiots.

Please respond to sci.math or email me any response to this.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558

Hi,

[Newsgroups line again shortened]

Randy Yates wrote:
> What I don't understand is why, once the decision
> has been made that portability/readability/maintainability is to be
> secondary to performance, assembly is a bad choice. As I just wrote in
> another thread, it isn't that awful. Is it? I mean, folks here argue
> as if it takes MAN-YEARS to write a single assembly routine.

Because it does take man-years? :-)

I think nobody doubts that solving a given problem of sufficient size
(i.e. more than just "compute a 2nd-order IIR filter") in assembly takes
longer than solving the same problem in a high-level-language, be it C
or something "higher". The high-level-language programmer will thus
simply be ready before the all-in-asm programmer. Most of the time, the
product will be "good enough" in terms of performance. And if it's too
big or too slow, he still has enough time left to find and eliminate the
performance eaters.

Hence, saying "I'll do it in only asm to get best possible performance"
is useless, because usually you only need good-enough performance. Asm
is a useful addition to a high-level-language, but nothing to start a
(sufficiently large) project in.


Stefan

In article <IICdnb-H28SwMTbbnZ2dnUVZ_tbinZ2d@rcn.net>,
Jerry Avins <jya@ieee.org> wrote:
>gyansorova@gmail.com wrote:
>> On Jul 29, 2:18 am, Randy Yates <ya...@ieee.org> wrote:

................

>>> Also note that requiring the programmer to know the processor architecture
>>> defeats, at least in part, the point of a high-level-language since time
>>> is spent learning things that ideally would be handled by the compiler.

The compiler cannot handle them, as the programmer might want
to do something the compiler writer did not envision.

>>> Note that this is absolutely irrefutable. The C language (and every other
>>> computer language that I know of) is not capable of optimizing this BECAUSE
>>> IT DOESN'T HAVE CONTROL OVER DATA ALIGNMENT AND STRUCTURE.

It does, to some extent, but not enough.


>> I have a feeling that data-flow is the answer. Check out the latest
>> LabView. You must think differently.Sequencial code will die.

This is not enough, and also false. There are ways of writing
non-sequential code sequentially.

>Until processors routinely execute and n instructions in parallel, all
>code will be executed sequentially. You might as well write it that way.

This has been false for a long time. Instructions may be
issued sequentially, but might not be executed sequentially.
This can even cause errors in a high-level language, where
two subroutines can write to the same memory locations, and
if the modules executing those are parallel, the wrong one
can write first. Such blocks can be put in hardware, but
they can be circumvented without too much effort. This can
easily happen on an MIMD machine, unless the programmer puts
in the appropriate signaling.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558

Rune Allnor wrote:
> On 30 Jul, 11:34, "Wade Ward" <zaxf...@invalid.net> wrote:
>
>> Tim has regular comment if c.l.f., fortran being a common extension of C.
>
> Really? That's new to me. According to the myths I've
> heard, Fortran was developed alongside the first usable
> computers in the '50s and early '60s. As I know the
> language, that might very well be true (code start in
> column 7, lines no longer than to column 72, no line
> breaks inside statements, awkward function call
> specifications, either '!' or 'C' as comment indicators,
> and so on). C, on the other hand, was apparently
> developed alongside UNIX in the late '60s / early '70s.
>
> If this is correct, I find a claim that "fortran is an
> extension of C" very hard to believe. If such a claim
> really has been made -- I read from comp.dsp -- I would
> very much like to see the evidence to justify it.

I suspect that you misinterpreted Wade because you were foolish enough
to accept what he wrote. :-)

There's a lot of good Fortran code, much of it as libraries of
subroutines. The calling sequences for calling Fortran routines differs
from C, but it's common for C compilers to allow the Fortran calling
sequence in order to make those libraries useful as C extensions.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

In article <1185677476.223390.5560@r34g2000hsd.googlegroups.c om>,
robert bristow-johnson <rbj@audioimagination.com> wrote:
>On Jul 28, 4:50 pm, Jerry Avins <j...@ieee.org> wrote:

>> Until processors routinely execute and n instructions in parallel, all
>> code will be executed sequentially. You might as well write it that way.

>and if instructions have conditionals in them, those would have to be
>executed sequentially, despite the brawn, no?

No. A conditional branch can be executed before all the
already issued instructions are finished. Whether this
can happen depends on the hardware; I do not know if the
CYBER 205 had such blocks on a conditional after a vector
instruction, and vectors could be quite long.

>r b-j



--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558

Wade Ward wrote:
> "Tim Prince" <timothyprince@sbcglobal.net> wrote in message
> news:ZqKqi.122$IE5.71@newssvr17.news.prodigy.net.. .
>> hel@40th.com wrote:
>>> Check Intel's marketing for its C/C++ compiler.
>>> I'm sure in there somewhere is how it detects
>>> SOA/AOS requirements and reorders data, and
>>> vectors it all using SSE2/3/4 for best effect.
>>> I'm almost as sure that MS/VS will do the same.
>> If you checked the marketing, you might have seen that Intel C++
>> implements complex data type auto-vectorization for SSE3, but requires C99
>> syntax for that. Since you are cross-posting to c.l.f, you might consider
>> that some people would prefer to use Fortran rather than less optimal asm
>> hacks. Sorry if you are put off by flashbacks to the days when people
>> called Fortran functions from COBOL rather than do asm. Beats me why
>> people would rather use asm than embed C99 in C++ or C89. Don't know
>> whether you consider the <?intrin.h> stuff to be assembly.
> Tim has regular comment if c.l.f., fortran being a common extension of C.
> As such, it has a standard.
>
> My experience in assembly would lead me to believe that it just might not
> have a standard, as it is so close to many OS/hardware questions. I have
> two questions:
> 1) Does assembly have a standard?

There is a different assembly language for every processor family, and
dialects peculiar to particular members of that family. There are some
broad conventions, but I doubt that you mean that, so I won't try to
enumerate some of them.

> 2) If fortran binds C, and C binds assembly, does Fortran bind assembly?

Bind? Like Immodium?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Walter Banks wrote:

...

> C99 compilers that implement ISO/IEC 18037 have full access
> to the flag bits and all processor registers.

Wonderful! How is that done portably?

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Stefan Reuther wrote:
> Hi,
>
> [Newsgroups line again shortened]
>
> Randy Yates wrote:
>> What I don't understand is why, once the decision
>> has been made that portability/readability/maintainability is to be
>> secondary to performance, assembly is a bad choice. As I just wrote in
>> another thread, it isn't that awful. Is it? I mean, folks here argue
>> as if it takes MAN-YEARS to write a single assembly routine.
>
> Because it does take man-years? :-)
>
> I think nobody doubts that solving a given problem of sufficient size
> (i.e. more than just "compute a 2nd-order IIR filter") in assembly takes
> longer than solving the same problem in a high-level-language, be it C
> or something "higher". The high-level-language programmer will thus
> simply be ready before the all-in-asm programmer. Most of the time, the
> product will be "good enough" in terms of performance. And if it's too
> big or too slow, he still has enough time left to find and eliminate the
> performance eaters.
>
> Hence, saying "I'll do it in only asm to get best possible performance"
> is useless, because usually you only need good-enough performance. Asm
> is a useful addition to a high-level-language, but nothing to start a
> (sufficiently large) project in.

Check out http://www.grc.com/default.htm (Gibson Research).
Gibson writes all his code in assembly, including graphics.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins <jya@ieee.org> writes:
> Walter Banks wrote:
> > C99 compilers that implement ISO/IEC 18037 have full access
> > to the flag bits and all processor registers.
>
> Wonderful! How is that done portably?

It's not really intended to be "portable" as such (except within
closely related chip families). It's meeting in the middle, a
syntactic sugar which permits the high level language to address
low level concepts without resorting to __asm. It permits the
programmer, or the chip vendor's toolchain header files, to
declare a variable which represents the such-and-such register.
The toolchain knows that when it sees the declaration it's
supposed to use a certain hardware register for that variable.
It is independent of the declaration of the type of the variable,
so that you can declare a flags register as being a struct of
bitfields if you so desire, or just an unstructured integer
type, if you'd prefer that. Neither would be of any relevance
to an unrelated architecture.

So it enables you to concretise the underlying architecure,
more than abstracting it.

Phil
--
Dear aunt, let's set so double the killer delete select all.
-- Microsoft voice recognition live demonstration

In article <1185722378.498383.20410@d55g2000hsg.googlegroups. com>,
William Hughes <wpihughes@hotmail.com> wrote:
>On Jul 29, 10:19 am, Randy Yates <ya...@ieee.org> wrote:
>> Phil Carmody <thefatphil_demun...@yahoo.co.uk> writes:
>> > [...]
>> > But of course that's the programmer taking control.

>> To some extent it is, but if you need to "take control," and
>> you must delve into architecture specifics and write non-portable
>> C code (at least C code that won't run _fast_ on multiple platforms),

>A far cry from non-portable code.

Consider the badly designed C function frexp. If executed
as a function call AT ALL, the function call is likely to
be more costly in time and space than inlining it using
assembler instructions, on whatever machine it is to be
executed. It also should not use the C language; this is
one clear place where an adequate HLL would have to have
more than one argument to the left of the replacement call.

Another bad example is the switch operator. It requires
an argument for the switch process, and also requires a
return to the switch operator even if one knows where to
go. In this case, the "argument" should be kept in the
location ONLY; this removes an argument assignment, using
a multibranch test on argument, as well as a simple
transfer when a simple transfer would do as well. This
CAN be avoided in C by a liberal use of goto's, which
the HLL advocates demean.

A semi-HLL assembler can be produced which is easy to
read and write, and almost as concise as a HLL. One
could include important instructions which HLLs handle
badly. How one carries out multiple precision operations
depends heavily on the architecture, and architectures
are declining in their ability to do this well.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Department of Statistics, Purdue University
hrubin@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558