Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Someone Told Me: Is C an Assembly Language (http://www.velocityreviews.com/forums/t959319-someone-told-me-is-c-an-assembly-language.html)

clusardi2k@aol.com 04-02-2013 09:31 PM

Someone Told Me: Is C an Assembly Language
 
Years ago, someone told me once that C is assembly language. Is this true. Do you have any proof why or why not.

Thanks,

Ian Collins 04-02-2013 09:36 PM

Re: Someone Told Me: Is C an Assembly Language
 
clusardi2k@aol.com wrote:
> Years ago, someone told me once that C is assembly language. Is this
> true. Do you have any proof why or why not.


Read through all of the dozens (if not hundreds) of similar trolls for
your answer.

--
Ian Collins

Keith Thompson 04-02-2013 11:21 PM

Re: Someone Told Me: Is C an Assembly Language
 
clusardi2k@aol.com writes:
> Years ago, someone told me once that C is assembly language. Is this
> true. Do you have any proof why or why not.


No, C is not an assembly language.

Assembly language programs specify CPU instructions.
C programs specify behavior.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

James Kuyper 04-02-2013 11:50 PM

Re: Someone Told Me: Is C an Assembly Language
 
On 04/02/2013 05:31 PM, clusardi2k@aol.com wrote:
> Years ago, someone told me once that C is assembly language. Is this true. Do you have any proof why or why not.


The answer to this depends upon what you mean by "assembly language".
Wiktionary says "(computing) A programming language in which the source
code of programs is composed of mnemonic instructions, each of which
corresponds directly to a machine instruction for a particular processor."

This definition is completely consistent with every use I'd ever seen of
the term until quite recently, including all three assembly languages
I've programmed in. It does not fit C at all. C is not oriented to a
particular processor, and does not specify the machine instructions to
be generate. It only specifies what the machine instructions must do; it
is perfectly legal for a C compiler to generate any sequence of machine
instructions that produces the specified result, and what the C standard
fails to mandate allows a great many alternative ways of translating any
particular C program into machine instructions.

However, the last time I ever programmed in assembly language was two
decades ago. I've recently been informed that the distinction between
modern assembly languages and higher level languages has become so fuzzy
as to have pretty much completely disappeared. The person who said this
claimed that modern assembly languages no longer implement a one-to-one
relationship between assembly language instructions and machine language
instructions, but are free to choose from a wide variety of possible
translations. Also, he claimed that modern assembly languages are no
longer restricted to a particular processor, that the same assembly code
can be used to generate different machine code on different platforms,
even if they have significantly different architectures. On the basis of
that claim, he asserted that, since the same was true of C, C could
therefore be classified as an assembly language. To me, it would seem
more reasonable to say that the languages he described (if he was
describing them correctly) were now high level languages, and no longer
assembly languages.



Keith Thompson 04-03-2013 01:06 AM

Re: Someone Told Me: Is C an Assembly Language
 
James Kuyper <jameskuyper@verizon.net> writes:
> On 04/02/2013 05:31 PM, clusardi2k@aol.com wrote:
>> Years ago, someone told me once that C is assembly language. Is this
>> true. Do you have any proof why or why not.

>
> The answer to this depends upon what you mean by "assembly language".
> Wiktionary says "(computing) A programming language in which the source
> code of programs is composed of mnemonic instructions, each of which
> corresponds directly to a machine instruction for a particular processor."
>
> This definition is completely consistent with every use I'd ever seen of
> the term until quite recently, including all three assembly languages
> I've programmed in. It does not fit C at all. C is not oriented to a
> particular processor, and does not specify the machine instructions to
> be generate. It only specifies what the machine instructions must do; it
> is perfectly legal for a C compiler to generate any sequence of machine
> instructions that produces the specified result, and what the C standard
> fails to mandate allows a great many alternative ways of translating any
> particular C program into machine instructions.
>
> However, the last time I ever programmed in assembly language was two
> decades ago. I've recently been informed that the distinction between
> modern assembly languages and higher level languages has become so fuzzy
> as to have pretty much completely disappeared. The person who said this
> claimed that modern assembly languages no longer implement a one-to-one
> relationship between assembly language instructions and machine language
> instructions, but are free to choose from a wide variety of possible
> translations. Also, he claimed that modern assembly languages are no
> longer restricted to a particular processor, that the same assembly code
> can be used to generate different machine code on different platforms,
> even if they have significantly different architectures. On the basis of
> that claim, he asserted that, since the same was true of C, C could
> therefore be classified as an assembly language. To me, it would seem
> more reasonable to say that the languages he described (if he was
> describing them correctly) were now high level languages, and no longer
> assembly languages.


I remember that discussion, but not all the details of it. As I
recall, the person making that claim, when repeatedly pressed for
concrete examples, backed away from it.

Still, the Wiktionary definition ignores the macro processing
available in many assemblers.

My definition, given elsethread, is that an assembly language program
specifies a sequence of CPU instructions; it needn't necessarily
do so on a one line to one instruction basis.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

glen herrmannsfeldt 04-03-2013 01:24 AM

Re: Someone Told Me: Is C an Assembly Language
 
James Kuyper <jameskuyper@verizon.net> wrote:
> On 04/02/2013 05:31 PM, clusardi2k@aol.com wrote:
>> Years ago, someone told me once that C is assembly language.
>> Is this true. Do you have any proof why or why not.


> The answer to this depends upon what you mean by "assembly language".
> Wiktionary says "(computing) A programming language in which the
> source code of programs is composed of mnemonic instructions,
> each of which corresponds directly to a machine instruction for a
> particular processor."


Well, if you include macros, then that hasn't been strictly true
for many years now.

> This definition is completely consistent with every use I'd ever seen of
> the term until quite recently, including all three assembly languages
> I've programmed in. It does not fit C at all. C is not oriented to a
> particular processor, and does not specify the machine instructions to
> be generate. It only specifies what the machine instructions must do; it
> is perfectly legal for a C compiler to generate any sequence of machine
> instructions that produces the specified result, and what the C standard
> fails to mandate allows a great many alternative ways of translating any
> particular C program into machine instructions.


That is true. However, if you allow conversions between pointers
and integers, then you can do many operations that would otherwise
need to be done in assembly language. Conveniently, doing that tends
to make the C code machine dependent.

> However, the last time I ever programmed in assembly language was two
> decades ago. I've recently been informed that the distinction between
> modern assembly languages and higher level languages has become so fuzzy
> as to have pretty much completely disappeared. The person who said this
> claimed that modern assembly languages no longer implement a one-to-one
> relationship between assembly language instructions and machine language
> instructions, but are free to choose from a wide variety of possible
> translations. Also, he claimed that modern assembly languages are no
> longer restricted to a particular processor, that the same assembly code
> can be used to generate different machine code on different platforms,
> even if they have significantly different architectures. On the basis of
> that claim, he asserted that, since the same was true of C, C could
> therefore be classified as an assembly language. To me, it would seem
> more reasonable to say that the languages he described (if he was
> describing them correctly) were now high level languages, and no longer
> assembly languages.


I haven't actually used it, but there is an assembler for the
descendants of OS/360 that IBM calls "High Level Assembler."

For many years, people have been writing macros to help users by making
assembly lanugage look more like a high level language. For example,
macros to generate IF/THEN/ELSE structures or DO/WHILE. Macros that
keep track of nesting level and such. And assemblers have supplied more
and more complicated macro processing facilities, including the
evaluation of expressions, and conditional assembly based on those
expressions.

Even some small deviations from the strict definition have been needed
for some time. Some systems use different branch instructions for near
addresses from not so near. It is convenient to allow the assembler to
select the appropriate instruction when the offset is known.

Some C compilers allow for inline assembly code. That is, you can
mix C statements and assembly instructions in the same program.
That tends to work, as in enough cases one can predict the instructions
that the compiler will generate well enough that registers and symbolic
addresses are consistent.

I was some time ago writing in Dynamic C (that is the name of the
compiler) for the Rabbit (descendant of the Z80) processor. It is very
easy to switch between assembler and C, and there are few enough
registers that you always know what is where. You can, for example,
easily write a C for loop where the loop body contains assembler
instructions. Trust the C compiler to do the loop right, and code
exactly what you need inside the loop. C variables can be referenced
in the usual way as symbolic names in the assembler.

The real answer is that, no, C is not assembler but often it is close
enough that it can be used that way.

-- glen


glen herrmannsfeldt 04-03-2013 01:35 AM

PL/360, was: Re: Someone Told Me: Is C an Assembly Language
 
James Kuyper <jameskuyper@verizon.net> wrote:
> On 04/02/2013 05:31 PM, clusardi2k@aol.com wrote:
>> Years ago, someone told me once that C is assembly language.
>> Is this true. Do you have any proof why or why not.


To see what can actually be done in the range between high level
languages and assembly language, consider PL/360.

PL/360 was designed by Niklaus Wirth around 1968. It has a structure
similar to PL/I, but in operation, it is more like a S/360 assembler.

It allows one to forget about some of the complications of writing
machine instructions in symbolic form, but not all of them.

R1:=R2;

copies the value from machine register 2 to machine register 1,
easy enough.

R2:=R2+R2;

doubles the value in register 2.

R2:=R2+R2+R2;

quadruples the value in register 2. Surprised?

LR R2,R2
AR R2,R2
AR R2,R2

note that unlike most high-level languages, the whole expression is not
evaluated before changing the left side of the assignment operator.

But then C programmers know that sometimes you have to be careful about
when variables get updated, too.

-- glen

clusardi2k@aol.com 04-03-2013 12:38 PM

Re: PL/360, was: Re: Someone Told Me: Is C an Assembly Language
 
So trying to sum all this up, the question of whether or not C is an assembly language is currently no!

Am I correct in my "no" assumption, or is it a more appropriate answer to say yet to be determined via a mutually agreed apon definition.

Is this question just an academic one.

Thanks,

BartC 04-03-2013 12:57 PM

Re: PL/360, was: Re: Someone Told Me: Is C an Assembly Language
 


<clusardi2k@aol.com> wrote in message
news:109716da-0f13-4403-bb27-a91501a954f2@googlegroups.com...
> So trying to sum all this up, the question of whether or not C is an
> assembly language is currently no!
>
> Am I correct in my "no" assumption, or is it a more appropriate answer to
> say yet to be determined via a mutually agreed apon definition.


You wouldn't be far wrong in saying 'no'.

Try some actual C compilers, see if there is an option to generate assembly
code (for example, the -S option with gcc). Then look at this output, and
see if it bears any resemblance to the original source.

This assembly output is what people are trying to avoid by writing C code
instead.

--
Bartc


James Kuyper 04-03-2013 02:56 PM

Re: Someone Told Me: Is C an Assembly Language
 
On 04/02/2013 09:06 PM, Keith Thompson wrote:
....
> I remember that discussion, but not all the details of it. As I
> recall, the person making that claim, when repeatedly pressed for
> concrete examples, backed away from it.


That discussion was so fresh in my memory that I was surprised to find
it occurred nearly two years ago. "He" was Rui Maciel, and the thread
Subject: was "for your languages". Rui never backed down from his claim,
he just failed to respond to requests for concrete examples.

My own understanding is that the purpose of an assembly language is to
provide a convenient mechanism for specifying the precise sequence of
machine language instructions to be generated, which is therefore
inherently platform dependent. Macros are merely a convenient way of
packaging specification of a large number of instructions into one
piece. An assembler that produces a different sequence of machine
instructions from the one specified, is defective. Assembly code
intended for one platform cannot be usefully ported to a radically
different platform, precisely because, by "radically different", I mean
a platform for which a wildly different sequence of machine code
instructions would be needed to generate the same desired behavior.

One of the key purposes for higher level languages like C is to avoid
having to specify the precise sequence of machine language instructions.
Instead, C code specifies only the desired behavior, and leaves it up
to the implementation to decide which machine language instructions to
generate. The same C code can be used to generate many different
sequences of machine code, without rendering the implementation
non-conforming, so long as all of those sequences implement the
specified behavior. C compilers for wildly different platforms will
produce wildly different sequences of machine language instructions,
that implement the same behavior - producing that result is precisely
one of the purposes for designing higher level languages like C.

Rui claimed (but never provided a concrete example) that in modern
usage, "macro assembly language" is used to refer to things that I would
call a "high level language", and that things that I would consider it
proper to call "assembly languages" had become obsolete so long ago that
had never existed during his career. He pointed out that typical C
implementations deterministically generate specific sequences of machine
language instructions when given a specific C program as input, and
therefore concluded it was appropriate to call C an assembly language,
despite the fact that different C compilers had different deterministic
mappings, without ceasing to be conforming. Also, the determinism of the
process was merely a convenience, and is not required of a conforming
implementation of C - that didn't faze him, either.
--
James Kuyper


All times are GMT. The time now is 09:19 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.