Thoughts on the C/Assembly Debate

In article <9KudnXlgNPEJ7y3bnZ2dnUVZ_j-dnZ2d@rcn.net>,
Jerry Avins <jya@ieee.org> wrote:
[...]

Speaking of portability, you put characters in you signature
with the high bit set.

--
Michael Press

"Gib Bogle" <bogle@ihug.too.much.spam.co.nz> wrote in message
news:f8qs2u$vd1$1@lust.ihug.co.nz...
> Androcles wrote:


>> If you can't write normal English syntax how the fuck do you expect a
>> compiler to translate and assemble your code?
>
> I suspect that he doesn't expect any compiler to translate and assembly
> his English text.
He's obnoxious.
--
Wade Ward

Chip Eastham wrote:
> On Aug 1, 2:10 pm, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
>
>> In article <zaCdnQMdrPKvjS3bnZ2dnUVZ_snin...@comcast.com>,
>> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>>> To me the problem with doing inline assembly is that
>>> you don't know which registers the compiler is already
>>> using. For the 8080 that doesn't matter much because
>>> it doesn't have enough registers for any to be in
>>> use, but for many processors it does.
>
>> One should be able to communicate with the compiler, and
>> to give it directions. Also, one should be able to use
>> variable registers, and there are things which compilers
>> seem unwilling or unable to know.
>
> I think a common strategy is to push the contents
> of some or all registers onto the stack as the
> very first step in an inline assembly snippet.
> One then pops these values back into the same
> registers when the inline assembly code ends.

What a waste of time! With a compiler like that, I would edit the
assembly output to remove the pushes and pops of the registers my
assembly doesn't use. With the Forths I use, I know which registers the
kernel uses and just avoid them.

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

On Aug 1, 8:12 pm, Randy Yates <ya...@ieee.org> wrote:
> glen herrmannsfeldt <g...@ugcs.caltech.edu> writes:
> > (snip, someone wrote)
> >>>Well, this is not optimized! Never can be, because C can't restructure
> >>>the "data[]" array to put the real and imaginary parts into individual,
> >>>continuous arrays.
> > (snip)
>
> >>>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.
>
> > See:http://gcc.gnu.org/ml/gcc-bugs/2007-03/msg01324.html
>
> > Some C compilers do change an array of structs to struct of arrays,
> > or the other way around.
>
> I wonder how you're supposed to debug something like that?!

Hopefully using a symbolic debugger capable of naming
or finding all the scrambled memory locations. It can be
a real bear to debug coding errors that stop misbehaving
when you turn the compiler optimizations off.


IMHO. YMMV.
--
rhn A.T nicholson d.0.t C-o-M

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

C compilers have control over data alignment. The implementation may modify
the structures in implementation but the symbolic debugging needs to reflect
where data actually is.

This is also true in some surprising ways with simple variables that are in
registers for part of their lifetime. The symbolic debugging simply tracks
where the variable currently is.

Regards

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

Ron N. wrote:
> On Aug 1, 8:12 pm, Randy Yates <ya...@ieee.org> wrote:

(snip, I wrote)

>>>Some C compilers do change an array of structs to struct of arrays,
>>>or the other way around.

>>I wonder how you're supposed to debug something like that?!

> Hopefully using a symbolic debugger capable of naming
> or finding all the scrambled memory locations. It can be
> a real bear to debug coding errors that stop misbehaving
> when you turn the compiler optimizations off.

See:
http://gcc.gnu.org/onlinedocs/gcc/Complex.html

regarding debuggers for gcc's Complex variables, where, it seems,
this can happen.

-- glen

Walter Banks <walter@bytecraft.com> writes:

>> 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.
>
> C compilers have control over data alignment. The implementation may modify
> the structures in implementation but the symbolic debugging needs to reflect
> where data actually is.
>
> This is also true in some surprising ways with simple variables that are in
> registers for part of their lifetime. The symbolic debugging simply tracks
> where the variable currently is.
>
> Regards
>
> Walter Banks

Hi Walter,

I see no end to this debate, and I see no fruit in attempting to
communicate the multiple issues that come up in my mind when I read
the statements you and others make on this issue.

However, know this with certainty: Nothing that has been stated here,
by you or anyone else, has changed reality, and that reality is that I
can write code in assembly that consistently, over multiple compiler
vendors, platforms, processors, and software development epochs (the
70's, 80's, 90's, etc.), that beats the pants off a compiler.

So I have no problem if you choose to continue to attempt to use a C
compiler to do a good assembly language programmer's job. In fact, I'm
banking on it.
--
% Randy Yates % "She has an IQ of 1001, she has a jumpsuit
%% Fuquay-Varina, NC % on, and she's also a telephone."
%%% 919-577-9882 %
%%%% <yates@ieee.org> % 'Yours Truly, 2095', *Time*, ELO
http://home.earthlink.net/~yatescr

Walter Banks wrote:

(snip)

> This is also true in some surprising ways with simple variables that are in
> registers for part of their lifetime. The symbolic debugging simply tracks
> where the variable currently is.

One that I have seen in debuggers with C is that sometimes function
dummy variables aren't set by the first executable statement. It may
be that they are still in registers, and will be stored later.

More related to Fortran is what ENTRY looks like, at least in
gfortran and g95. (I believe both.) Each ENTRY point, including
the primary entry, is a separate function which then calls another
function (in the C sense) that contains all the code. It is
especially noticeable when using breakpoints.

-- glen

"Gib Bogle" <bogle@ihug.too.much.spam.co.nz> wrote in message
news:f8qs2u$vd1$1@lust.ihug.co.nz...
: Androcles wrote:
: > "William Hughes" <wpihughes@hotmail.com> wrote in message
: > news:1185831281.136214.163410@q75g2000hsh.googlegr oups.com...
: > : On Jul 30, 4:58 pm, hru...@odds.stat.purdue.edu (Herman Rubin) wrote:
: > : > In article <1185822779.498334.240...@r34g2000hsd.googlegroups .com>,
: > : > William Hughes <wpihug...@hotmail.com> wrote:
: > : >
: > : >
: > : >
: > : > >On Jul 30, 2:02 pm, hru...@odds.stat.purdue.edu (Herman Rubin)
wrote:
: > : > >> In article
<1185722378.498383.20...@d55g2000hsg.googlegroups. com>,
: > : > >> William Hughes <wpihug...@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.
: > : > >I fail to see your point. When the compiler sees the
: > : > >function frexp it can emit the appropriate machine
: > : > >code without a function call.
: > : > >Compilers can always use compiler magic on
: > : > >a library fuction. [Sure I can force the compiler to use
: > : > >a function call and this will slow things down.
: > : > >So what? There are lots of stupid things I can do to
: > : > >defeat optimization]
: > : >
: > : > The form of frexp was b = frexp(a, &m), which
: > : > meant that, unless a = 0, .5 <= |b| < 1, and
: > : > a = 2^m*b. The form of this statement forces
: > : > m into memory.
: > :
: > : No, as I point out the fact that it looks like
: > : m has an address, does not mean that m cannot
: > : be a register.
: > :
: > : > To avoid this, one would have
: > : > to write
: > : >
: > : > b, m = frexp(a)
: > : >
: > : > >Or is your point that the compiler cannot store the
: > : > >exponent in a register. This is simply false.
: > : > >The abstract machine cannot store the exponent in a register
: > : > >but the abtract machine does not have the concept of register.
: > : >
: > : > Alas, the abstract machine needs the concept of a register.
: > :
: > : Nonsense. We obviously do not share the same concept of
: > : abstract machine.
: > :
: > : >
: > : > >The compiler can use a register for any variable
: > : > >it wants. (If the address of this variable is taken
: > : > >then the compiler has to be able to determine that
: > : > >the address is not actually needed, trivial here).
: > : >
: > : > Not if the address of the variable is explicitly given.
: > : >
: > :
: > : If the address of the variable is explicitly given then
: > : things are not quite as trivial, but the compiler can
: > : still determine that the address of the variable is only
: > : used to determine where to store the variable.
: > :
: > : > True you
: > : >
: > : > >cannot use a "register" qualifier for the variable
: > : > >used to store the exponent, but in theory we are
: > : > >allowed to assume that the compiler is as good or better
: > : > >than a good assembly programmer
: > : > >at chosing which variable should go into registers
: > : > >(the fact that this is true in practice is only icing
: > : > >on the cake)
: > : >
: > : > It is true in practice? Not to my knowledge.
: > :
: > : Not to my direct knowledge. It is frequently asserted.
: > : In any case, whether it is true or not in practice is
: > : beside the point. The point is that it can be considered
: > : to be true in theory.
: > :
: > : >
: > : > >> 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.
: > : > >There is nothing to stop the compiler from recognizing
: > : > >when a switch construct can be simplified in the way
: > : > >you describe and doing exactly what you describe.
: > : > >Again you seem to think that if there is an assignment
: > : > >in the abstract machine, the compiler must use
: > : > >and assignment. This is nonsense.
: > : >
: > : > I doubt that the compiler will be able to recognize that
: > : > the switch variable is ONLY going to be used in the
: > : > switch statement, nor will it recognize that a setup
: > : > like that may call for additional entries from outside
: > : > the subroutine.
: > :
: > : I do not know about existing compilers. There
: > : is certainly no theoretical barrier
: >
: > <syntax error 233> Statement terminator expect.
: > Intelligent compiler recovered from error.
: >
: >
: > : > I have not noticed additional entries
: > : > to a function or subroutine in any HLL since early
: > : > versions of Fortran, and few assemblers even have them.
: > : > One problem is the return statement.
: > :
: > : Explicit entry points are not needed. If the compiler
: > : can determine that such entry points are useful and
: > : it can create them.
: >
: > <syntax error 234> Unexpected statement terminator. "then" statement
: > expected after "if" statement followed by "and" statement.
: > Compilation terminated, unrecoverable error.
: >
: > If you can't write normal English syntax how the fuck do you expect a
: > compiler to translate and assemble your code?
:
: I suspect that he doesn't expect any compiler to translate and assembly
: his English text.

If-then-else is required in all language, although 'else' is often just the
default.

When I wrote code I always included "close" with every "open" before
I wrote the code in between. Same with "malloc" (memory allocation)
and "free". If I don't remember to do it at the time then I'm likely
to forget later, the program runs just fine for a while in the testing stage
and then crashes when it's passed to a customer with embarrassing
consequences.
Nobody is going to write code sequentially the first time and not need
to edit it, so work in paired keywords which are needed anyway and
fill in the gap.
http://en.wikipedia.org/wiki/Malloc

In article <46B0FAB7.4BB6E286@bytecraft.com>,
Walter Banks <walter@bytecraft.com> wrote:


>Herman Rubin wrote:

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

>The argument of a switch operator in C is naturally scoped
>and therefor known to the compiler. Most current
>implementations use data flow analysis to select one of
>several code generation sequences. Multibranch is
>the alternative if other possibilities have failed to be used for
>some reason.

>w..


I have an example of a highly branched program consisting
of three parts, call them stage 1, stage 2, and stage 3.
Stage 3 is simple and gives no problems. There are many
alternatives for stage 1, which make slight differences
in stage 3, but stage 2 is constant.

Stage 1 produces the input for stage 2, which is a program
of the above type. Except in rare cases, in which stage 2
starts with a "high" (default) value of the variable, stage
1 knows which case in stage 2 occurs, and should transfer
to that directly. Although stage 2 is heavily branched, it
is small; no branch is highly predictable (the highest
prediction probability is 2/3). BTW, the "default" part
should be placed where it interferes least with the running
of the program.


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