Making Fatal Hidden Assumptions

On Fri, 17 Mar 2006 02:13:49 GMT, Keith Thompson wrote:
>"Alf P. Steinbach" <alfps@start.no> writes:
>> * Keith Thompson:
...
>Apparently I have failed utterly to make myself clear.  I'll try one
>last time.
>
>You claim that C is, in some sense, an assembly language
>(specifically, a "portable assembly language").  I'm assuming here
>that any "portable assembly language" is an "assembly language".
>
>I claim that C is not an "assembly language", though it may bear some
>resemblance to one.

i don't know what "portable assembly language" is (because for an
assembly there is a cpu and "<=" [even a virtual cpu]), 
but C language can be assembly language for example for 386 cpu if
0) it is used the right subset of the language
1) registers and sub registers have C names
2) have the "push" instruction and a set of macros for all 386 cpu
instructions 

for example

#include <stdio.h>
#include <string.h>
#include <cpu_386.h>

int  main(int  argc,  char** argv)
{push  _ebx
    _ebx=argv; if(!(_ebx==0))  goto c1;
c0:       {pop  _ebx; _eax^=_eax; return;}
c1: _ebx= *ebx_;  /* ebx= argv[0]*/
    if(_ebx==0) goto c0;
    strrchar(_ebx, "prog.exe");
    if(_eax==0) goto c0;
    _ebx=_eax; _ebx+=sizeof("prog.exe"); _ebx=*_ebx;
    if(!(_ebx==0)) goto c2;
          {printf("i nomi sono uguali\n");  }  
c2:       {printf("il nome &#4294967295; pi&#4294967295; lungo \n");}
   goto  c0;
}

could be assembly

RSoIsCaIrLiIoA wrote:
> but C language can be assembly language for example for 386 cpu if
> 0) it is used the right subset of the language
> 1) registers and sub registers have C names
> 2) have the "push" instruction and a set of macros for all 386 cpu
> instructions

Nonsense. C is not and cannot be an assembly language, portable or
otherwise. Now *your* implementation of C might provide extensions, or
you might create them yourself to access specific features of the
target processor, but that is beside the point.

Standard C is not an assembly language, portable or otherwise. Anyone
who thinks so has a dilute conception of assembly language.

< snipped wierd inline assembly code >

On Sat, 18 Mar 2006 08:31:13 +0100, RSoIsCaIrLiIoA <zz@zz.z> wrote:

>#include <stdio.h>
>#include <string.h>
>#include <cpu_386.h>
>
>int  main(int  argc,  char** argv)
>{push  _ebx
>    _ebx=argv; if(!(_ebx==0))  goto c1;
>c0:       {pop  _ebx; _eax^=_eax; return;}
>c1: _ebx= *ebx_;  /* ebx= argv[0]*/
>    if(_ebx==0) goto c0;
>    strrchar(_ebx, "prog.exe");
>    if(_eax==0) goto c0;
>    _ebx=_eax; _ebx+=sizeof("prog.exe"); _ebx=*_ebx;
>    if(!(_ebx==0)) goto c2;
>          {printf("i nomi sono uguali\n");  }  
>c2:       {printf("il nome &#4294967295; pi&#4294967295; lungo \n");}
>   goto  c0;
>}
>
>could be assembly

but this seems to compile and to run here (Borland C compiler)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int  main(int  argc,  char** argv)
{   asm{push   ebx;}
/*     printf("arg0=%s\n", argv[0]);  */
    _EBX=argv; if(!(_EBX==0))  goto c1;
c0:       {asm{pop  ebx;} _EAX^=_EAX; return;}
c1: _EBX = *(int*)_EBX;  /* ebx= argv[0]*/
    if(_EBX==0) goto c0;
    strstr((char*)_EBX, "prog.exe");
    if(_EAX==0) goto c0;
    _EBX=_EAX; _EBX+=strlen("prog.exe");
    _BL = *(char*)_EBX; 
    if(!(_BL==0)) goto c2;
          {printf("i nomi sono uguali\n");  goto c3;}  
c2:       {printf("il nome e' piu' lungo \n");}
c3: goto  c0;
}

RSoIsCaIrLiIoA wrote:
> On Sat, 18 Mar 2006 08:31:13 +0100, RSoIsCaIrLiIoA <zz@zz.z> wrote:
> 
> >#include <stdio.h>
> >#include <string.h>
> >#include <cpu_386.h>
> >
> >int  main(int  argc,  char** argv)
> >{push  _ebx
> >    _ebx=argv; if(!(_ebx==0))  goto c1;
> >c0:       {pop  _ebx; _eax^=_eax; return;}
> >c1: _ebx= *ebx_;  /* ebx= argv[0]*/
> >    if(_ebx==0) goto c0;
> >    strrchar(_ebx, "prog.exe");
> >    if(_eax==0) goto c0;
> >    _ebx=_eax; _ebx+=sizeof("prog.exe"); _ebx=*_ebx;
> >    if(!(_ebx==0)) goto c2;
> >          {printf("i nomi sono uguali\n");  }
> >c2:       {printf("il nome &#4294967295; pi&#4294967295; lungo \n");}
> >   goto  c0;
> >}
> >
> >could be assembly
> 
> but this seems to compile and to run here (Borland C compiler)
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> 
> int  main(int  argc,  char** argv)
> {   asm{push   ebx;}
> /*     printf("arg0=%s\n", argv[0]);  */
>     _EBX=argv; if(!(_EBX==0))  goto c1;
> c0:       {asm{pop  ebx;} _EAX^=_EAX; return;}
> c1: _EBX = *(int*)_EBX;  /* ebx= argv[0]*/
>     if(_EBX==0) goto c0;
>     strstr((char*)_EBX, "prog.exe");
>     if(_EAX==0) goto c0;
>     _EBX=_EAX; _EBX+=strlen("prog.exe");
>     _BL = *(char*)_EBX;
>     if(!(_BL==0)) goto c2;
>           {printf("i nomi sono uguali\n");  goto c3;}
> c2:       {printf("il nome e' piu' lungo \n");}
> c3: goto  c0;
> }

PLONK

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

RSoIsCaIrLiIoA <zz@zz.z> writes:
> On Sat, 18 Mar 2006 08:31:13 +0100, RSoIsCaIrLiIoA <zz@zz.z> wrote:
[snip]
> but this seems to compile and to run here (Borland C compiler)
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
>
> int  main(int  argc,  char** argv)
> {   asm{push   ebx;}
> /*     printf("arg0=%s\n", argv[0]);  */
>     _EBX=argv; if(!(_EBX==0))  goto c1;
> c0:       {asm{pop  ebx;} _EAX^=_EAX; return;}
> c1: _EBX = *(int*)_EBX;  /* ebx= argv[0]*/
>     if(_EBX==0) goto c0;
>     strstr((char*)_EBX, "prog.exe");
>     if(_EAX==0) goto c0;
>     _EBX=_EAX; _EBX+=strlen("prog.exe");
>     _BL = *(char*)_EBX; 
>     if(!(_BL==0)) goto c2;
>           {printf("i nomi sono uguali\n");  goto c3;}  
> c2:       {printf("il nome e' piu' lungo \n");}
> c3: goto  c0;
> }

Please stop posting this non-portable non-standard crud in comp.lang.c.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

In article <2hjj12hb8ui6cldvdhd85s0ejgsijh14ue@4ax.com>, Al Balmer <albalmer@att.net> writes:
> 
> I should have quit when you first resorted to insulting those who
> disagree with you. Bye, now.

Pompous insults are Alf's usual recourse when he's confronted with
someone willing to point out that his arguments are vacuous.

I haven't killfiled him because he occasionally has something
worthwhile to say in technical discussions, but in an argument of
this sort it's best just to ignore him.  If past behavior is any
indication, he'll just try to shout everyone else down until we all
get tired of him and give up.

-- 
Michael Wojcik                  michael.wojcik@microfocus.com

The way things were, were the way things were, and they stayed that way
because they had always been that way.  -- Jon Osborne

* Michael Wojcik:
> In article <2hjj12hb8ui6cldvdhd85s0ejgsijh14ue@4ax.com>, Al Balmer <albalmer@att.net> writes:
>> I should have quit when you first resorted to insulting those who
>> disagree with you. Bye, now.
> 
> Pompous insults are Alf's usual recourse when he's confronted with
> someone willing to point out that his arguments are vacuous.
> 
> I haven't killfiled him because he occasionally has something
> worthwhile to say in technical discussions, but in an argument of
> this sort it's best just to ignore him.  If past behavior is any
> indication, he'll just try to shout everyone else down until we all
> get tired of him and give up.

Al chose to just insult me, in his first message  --  I don't know why, 
and generally I won't speculate what his reasons could be.

There is no technical content in your posting, but there is pack of lies 
and personal attacks, the usual hare-brained ad homimem attack.

Like I won't speculate about Al's reasons for going 100% personal, I 
won't speculate about your reasons.


-- 
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On 10 Mar 2006 10:16:54 -0800, "Ed Prochak" <edprochak@gmail.com>
wrote:

> 
> Richard G. Riley wrote:
> > "Ed"posted the following on 2006-03-10:
<snip: ++x versus x++>
> > How do you see them being different at the assembler level? They are
> > not are they? Its just when you do the (pseudo ASM) INC_REGx or ADDL 02,REGx or
> > whatever that matters isnt it?
> 
> Actuall I still think in PDP assembler at times (my first
> assemblerprogramming).
>  so y=x++; really does map to a single instruction which both moves the
> value to y and increments x (which had to be held in a register IIRC)

PDP was (almost) the entire product line of DEC for much of its life,
containing some similar architectures and some quite different ones
with (thus) different assembly languages.

You are probably thinking of PDP-11 autoincrement. This uses the
location _addressed_ by a register (only) which it increments (by
stride) at the same time:
register char * a = ?, b = *a++; // compiles to MOVB (R1)+, R2
register int * a = ?, b = *a++; // compiles to MOV (R1)+, R2
// note PDP-11 pointers are byte addresses & this adds _2_
// I write register explicitly for clarity, although a compiler could
// place variables not declared register in a register, and could
// choose not to use a register even though you specify it.

<snip other points about assy, macro assy, and C I mostly agree with>

- David.Thompson1 at worldnet.att.net

On 14 Mar 2006 10:52:28 -0800, "Ed Prochak" <edprochak@gmail.com>
wrote:

> 
> Keith Thompson wrote:
> > "Ed Prochak" <edprochak@gmail.com> writes:

> > But this is a common feature of many high-level languages.  Ada, for
> > example has an implementation-defined set of integer types, similar to
> > what C provides; I've never heard anyone claim that Ada is an
> > assembler.
> 
> Forgive my memory,but is it PL/1 or ADA that lets the programmer define
> what integer type he wants. Syntax  was something like
>      INTEGER*12  X
> defined X as a 12 bit integer. (Note that such syntax is portable in
> that on two different processors, you still know that the range of X is
> +2048 to -2047

You mean -2048 to +2047 for two's complement, and -2047 to +2047 for
the extremely rare case of non-2sC or 2sC-with-trap-representation.

PL/1 is like DECLARE X FIXED BINARY (11); /* not counting sign */
Pascal uses the actual range like X: -2047 .. +2047 and Ada similarly
except, as arguably usual, more verbosely in most cases. In both cases
you are only guaranteed _at least_ 12 bits; in Ada you can
additionally specify a 'representation clause' that requires exactly
12 bits (or a diagnostic if that can't be implemented).

The syntax INTEGER*n is a common extension in Fortran (though not
standard) for an integer of n _bytes_ not bits.

> The point is a 16bit integer in ADA is always a 16bit integer and
> writing
> x=32768 +10
> will always overflow in ADA, but it is dependent on the compiler and
> processor in C. It can overflow, or it can succeed.
> 
> But my point on this was, you need to know your target processor in C
> more than in a language like ADA. This puts a burden on the C
> programmer closer to an assembler programmer on the same machine than
> to a ADA programmer.
> 
I don't think this is true. In both languages it is fairly easy to do
portable but perhaps overconservative code. In C it is easy to get
fairly well 'down to the metal' if you want; in Ada it is fairly easy
to get even further down if the compiler supports it. And at the
extreme, Ada standardly requires an interface to assembler; C does not
do this standardly, but practically all implementations have some way.

<snip>
> No I was talking about the original motivation for the design of the
> language. It was designed to exploit the register increment on DEC
> processors. in the right context, (e.g. y=x++;)  the increment doesn't
> even become a separate instruction, as I mentioned in another post.
> 
Neither motivation nor correct effect; see other posts.

<snip>
> lets put it this way. there is a gradient scale, from pure digits of
> machine language (e.g., programming obcodes in binary is closer to the
> hardware than using octal or hex)
> at the lowest end and moving up past assebmler to higher and higher
> levels of abstraction away from the hardware. On that scale, I put C
> much closer to assembler than any other HLL I know. here's some samples
> 
s/much/noticeably/ and I agree. (Except see below.)

> 
> PERL, BASH, SQL

Also awk. (Although you could consider it subsumed by perl.) And all
Unix shells more or less not just bash. Also the LISP tribe (Scheme,
etc.) and Prolog here or perhaps a smidgen higher.

> C++, JAVA
> PASCAL, FORTRAN, COBOL

I'd insert Ada here.

> C

I'd insert FORTH here. And maybe pull some of the more powerful macro
assemblers above 'basic' assembler.

> assembler
> HEX opcodes
> binary opcodes

I wouldn't distinguish hex from binary; that's trivial.

I'd insert microcode and then registers/gates here.

> digital voltages in the real hardware.
> 
And below that turtles. <G>

- David.Thompson1 at worldnet.att.net

"Ed Prochak" <edprochak@gmail.com> wrote in message 
news:1142014614.683120.62680@i39g2000cwa.googlegroups.com...
> Some other languages do so much more for you that you might be scared
> to look at the disassembly. e.g. languages that do array bounds
> checking for you will generate much more code for  a[y]=x; than does C.
> You can picture the assembly code for C in your head without much
> difficulty. The same doesn't hold true for some other languages.

There are C compilers that will add bounds-checking code for a[y]=x, and 
it's quite ugly if disassembled.  I think what you mean is that C doesn't 
require implementations to do it (and most don't), but other languages do.

I shudder to think of what the asm would look like for a[y]=x if a were a 
C++ object with virtual methods for the [] and = operators, with the latter 
having to call a copy constructor on x.  For fun, compile as PIC too.

However, I agree with the general statement that when you write C, you have 
a good shot at imagining what the corresponding asm would be.  I'm not sure 
that makes it a glorified assembler, however.

C's greatest feature, and its worst, is that you can do all sorts of ugly 
unportable things that virtually no other HLL allows but also have portable 
constructs available: it's your choice which to use.  This means you can 
write non-portable implementation code in the same language as portable user 
code, and IMHO is the reason for C's enduring popularity.

S

-- 
Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin 

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***