Thoughts on the C/Assembly Debate

William Hughes wrote:
> The question is not: is the optimal
> assembler solution at least as good and possibly better that the
> optimal high level language solution? The answer to this
> is trivially yes.

I think the answer to that question is "out of the set of problems
that you could solve with a computer program, there exist problems
for which the optimal solution can only be achieved in assembly".
The answer is definitely not "for all programming problems, the
optimal solution can only be achieved with assembly". :-)

> The question is: is there something that can be done in
> assembly, that cannot be done, even in theory, in a high
> level language?

In theory, no. You can always add constructs to your high-level
language that do whatever you want. Want to check a bit for
overflow? Make a high-level construct that looks like exceptions:

try {
z = y + x;
} catch-numeric-overflow {
do_something();
}

Want to mask interrupts below level 5 for some hypothetical machine
during a section of code? Add a high-level construct that masks
interrupts for the scope of a block.

Basically, since the compiler is generating assembly (or machine
code directly), you can do whatever you want. A compiler just maps
machine constructs onto higher-level constructs. The fact that some
compilers leave out certain machine constructs does not mean all
compilers have to.

In particular, one could imagine a high-level language specifically
designed to be extensible to add new high-level constructs that make
available the low-level constructs of a particular platform.

- Logan

On Jul 29, 11:18 pm, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
> William Hughes wrote:
> > The question is not: is the optimal
> > assembler solution at least as good and possibly better that the
> > optimal high level language solution? The answer to this
> > is trivially yes.
>
> I think the answer to that question is "out of the set of problems
> that you could solve with a computer program, there exist problems
> for which the optimal solution can only be achieved in assembly".


Untrue, if you allow *any* compiler (this would include a compiler
that tries every possible sequence of machine instructions, selects
those sequences which duplicate the input sematics, performs timing
tests and choses the optimum", theoretical compilers are not limited
by mundane considerations like the size or lifetime of the universe).
If we restrict ourselves to the somewhat fuzzy concept of achievable
automatic compilers, the question of whether problems exist
for which the optimal solution can only be achieved by use of assembly
is the original qestion of this thread.




> The answer is definitely not "for all programming problems, the
> optimal solution can only be achieved with assembly". :-)
>
> > The question is: is there something that can be done in
> > assembly, that cannot be done, even in theory, in a high
> > level language?
>
> In theory, no. You can always add constructs to your high-level
> language that do whatever you want.


Yes, but this is equivalent to using assembly. For concreteness,
limit the high level language to the constructs which
exist in C. Are there problems for which the optimal assembly
solution cannot be produced by coding the problem
in a high level language and using an "achievable" compiler?

I do not think that the OP gave an example of such
a problem.

- William Hughes

On Sun, 29 Jul 2007 20:56:19 -0700, William Hughes wrote:

> Yes, but this is equivalent to using assembly. For concreteness,
> limit the high level language to the constructs which
> exist in C. Are there problems for which the optimal assembly
> solution cannot be produced by coding the problem
> in a high level language and using an "achievable" compiler?

There are plenty of compilers (the majority, these days, I suspect) that
have a much more blurry notion of what constitutes subroutines in the
traditional C ABI sense.

The later C standards allow a "hosted" compiler to treat the elements of
the C standard library as language elements, and is free to replace calls
to, say, memcpy() with in-line string copy instructions, or sequences of
word moves, or whatever: depending on what it can reason about the
situation in the code.

Similarly, and more particularly, there are the "intrinsic" libraries for
AltiVec, SSE[1-3] or ARMv5-M DSP instructions, where things that look like
function calls reliably translate to single in-line instructions. And
since they look like functions, there's no reason that you couldn't link
against a "pure C" library implementation on other platforms, but that's
certainly not the way you would use those. Rather, they would be used
within a (selection of) platform-dependent library(ies) that exposes some
specific functionality to a higher-level, portable progam body. Well,
that's the way I use them, anyway.

Then, on a completely different hand, there are whole families of
processors (starting with MIPS, and once including Alpha, and now TI C6000
and others) that were designed to support high level languages, and
essentially don't include any or much of the traditional
assembly-language-only architectural traits (no flags, for example). They
were designed to be coded in C (and Fortran, with support for most of the
other HLLs). Sure, you *can* write assembly for them (and there can be
useful performance to be gained that way on the in-order variants, where
scheduling is critical), but (at least on TI C6000) it's mostly just as
beneficial to tweak the C code while looking at the generated assembly
listings than actually writing assembly code by "hand". Once you allow
for feedback directed optimization (which includes just-in-time
compilation on some platforms and languages) even that hand coding
advantage can go away.

For all that, there are still (and particularly in the DSP field) a vast
array of processors for which raw assembly language is the only option.
That's just the way they are.

Cheers,

--
Andrew

William Hughes wrote:
> On Jul 29, 11:18 pm, Logan Shaw <lshaw-use...@austin.rr.com> wrote:
>> William Hughes wrote:

>>> The question is: is there something that can be done in
>>> assembly, that cannot be done, even in theory, in a high
>>> level language?
>> In theory, no. You can always add constructs to your high-level
>> language that do whatever you want.

> Yes, but this is equivalent to using assembly.

It's a well-known idea that the expressiveness of all computer
languages are equal except for a constant difference. If it takes
you N hours to code a solution to a problem in your favorite
language, then I can code a solution in my favorite language in
N + K hours (where K is the constant). This is easy to prove
since all I have to do in the worst case is write a translator
from one language to another (which takes K hours and only has
to be done once), then write the rest of the code in the other
language.

So in some sense, all languages are equivalent. But in practice,
K is often fairly large, and my point is that you can take the
machine constructs which C doesn't have a way to represent and
form high-level abstractions to use them.

> For concreteness,
> limit the high level language to the constructs which
> exist in C.

My point was that you *don't* have to limit the high-level
language to the constructs that exist in C! Different platforms
have different low-level constructs, and there is no reason that
high-level abstractions can't be created for them that could give
similar productivity gains like existing high-level abstractions
give.

> Are there problems for which the optimal assembly
> solution cannot be produced by coding the problem
> in a high level language and using an "achievable" compiler?

That's a very good point. I don't think the original poster
did give such an example. There is the small matter of the
difference between achievable compilers and actual compilers
that already exist today, but it's still a good point.

- Logan

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.

Rune

"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?

2) If fortran binds C, and C binds assembly, does Fortran bind assembly?
--
Wade Ward

"Rune Allnor" <allnor@tele.ntnu.no> wrote in message
news:1185783577.630655.95980@b79g2000hse.googlegro ups.com...
> 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.

Sometimes Wade's English grammar leaves me confused ;-)


According to the myths I've
> heard, Fortran was developed alongside the first usable
> computers in the '50s and early '60s.

True for "FORTRAN", but it has continued development (as "Fortran") through
into the 21st century. Though some people's mindset seems stuck in 1966
whenever Fortran is mentioned.
(Mind you 1966 was a good year - England won the soccer World Cup, I finally
passed my Chemistry exam needed for entry into the Physiscs course at Uni;
The Beatles, The Rolling Stones etc were heading for the "Summer of Love".
Aaah I remember the 60's - which means I didn't do it right! Right?) :-))

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,


No longer true. As I said things have moved on a bit over the years.

> awkward function call specifications,

A matter of taste I suppose in coding style. (Technically _subroutines_ are
"call"ed)
call mysub(list,of,arguments)
avalue = myfun(another,list,of,arguments)

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

As has been noted elsewhere "One can write a bad FORTRAN program in any
language"
I know, I wrote some terrible COBOL stuff in my early years. :-)

> 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.
>
> Rune
>


Les

Randy Yates wrote:

> 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),
> then assembly provides the ultimate "control."
>
> I wouldn't use the word "offend" - I consider it an abuse of the
> high level language.
>
> Hey People, this is ludicrous. All these arguments treat assembly
> as if it were the ultimate evil. It ain't that bad, folks. Honest.

If you need to switch to asm then that specific application will
not be portable. If the HLL can duplicate all of the functionality
that asm has then the advantages of the HLL are not lost.

Regards

Walter Banks
--
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com

Jerry Avins wrote:

> I know of no high-level language that gives the programmer access to
> flag bits like carry and overflow. Are there standard constructs for
> turning saturating arithmetic on and off? (That's not a rhetorical
> question. I don't know.) How about enabling and disabling specific
> interrupts and setting their priorities? Does C know about DMAs?

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

Regards


Walter Banks
--
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
walter@bytecraft.com

Logan Shaw wrote:
> William Hughes wrote:
>> The question is not: is the optimal
>> assembler solution at least as good and possibly better that the
>> optimal high level language solution? The answer to this
>> is trivially yes.
>
> I think the answer to that question is "out of the set of problems
> that you could solve with a computer program, there exist problems
> for which the optimal solution can only be achieved in assembly".
> The answer is definitely not "for all programming problems, the
> optimal solution can only be achieved with assembly". :-)
>
>> The question is: is there something that can be done in
>> assembly, that cannot be done, even in theory, in a high
>> level language?
>
> In theory, no. You can always add constructs to your high-level
> language that do whatever you want. Want to check a bit for
> overflow? Make a high-level construct ...

...

> In particular, one could imagine a high-level language specifically
> designed to be extensible to add new high-level constructs that make
> available the low-level constructs of a particular platform.

You don't need to imagine it. Forth has always done that. But no HLL can
do it portably across all platforms. For example, checking the carry
flag: the Alpha doesn't have one.

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