for your languages
io_x
BGB
> are you sure your langages are better than some type of macro-assembly?
>
apologies in advance for taking what seems to be troll bait...
but, anyways...
the main advantages of C and C++ over macro-assembly is that these
languages are far more readily portable (between OS's and CPU
architectures), whereas most macro-assemblers are still often very
specific to a particular OS and/or architecture, and, most often, to a
specific macro-assembler.
so, in this sense, they are "better"...
now, as for C vs C++, or something being "universally better", I don't
personally believe any such "universal betterness" exists.
ASM has its uses, and C also has its own uses. neither is ideal for what
the other is strong at.
much like, the strength of C++ is that it has lots of features...
and the strength of C is that it does not have these features...
to clarify:
C++ has lots of features which make programming in C++ arguably somewhat
nicer than programming in C.
but, most of these same features being absent from C, give it a much
simpler syntax, meaning it is much easier to use tools with it (either
having tools which automatically generate special-purpose code, or which
effectively parse the source code to mine information for use for other
purposes, such as gluing against custom HLL's, implementing reflection
mechanisms, ...).
another area is that C generally has a more standardized ABI than C++,
meaning that mixing code from different compilers is a little less
liable to blow up in ones' face.
but, for example, one can do things like Class/Instance OO or generic
containers or similar in C++, and not have it look so much like an
awkward and nasty mess. whereas in C, it is more common to use raw
structs and function pointers to do OO style tasks, and typically any
"container" style tasks have the logic written clean for the specific
type of object being contained (typically there is no real clear
separation between the "container" and "the thing being contained").
that, or one resorts to using dynamic-type checking for implementing
their containers (this is its own matter, along with using a garbage
collector, ...).
so, where a C++ programmer may think "std::sort", a C programmer may
resort to memorizing the quicksort algorithm and typing it out
on-demand, or a C++ user using "std::hash_map" vs a C programmer
proceeding to write out the logic for hashing and fetching values, ...
but, what is "best" is rarely as clear-cut as people make it out to be.
much like many people think Java is one of the best languages around,
and some of us can't bring ourselves to try to choke it down... it has
some merits (fairly clean language design, and many interesting
VM-related capabilities) and some drawbacks (such as being awkward to
use and often needing far more code to accomplish the same task, as well
as being rather awkward to use in mixed-language projects with C and
C++...).
and, meanwhile, I have my own scripting HLL (BGBScript), which sort of
resembles a mix of JavaScript, ActionScript, Java and a few other
languages (some other influences have included Scheme, Self, and
Erlang), and tries to offer a fairly transparent FFI (its main feature
at present is that it is smart enough to largely interface directly with
C-based APIs with little or no special treatment).
my "general" goal has then been an FFI no more particularly difficult to
use than C++'s 'extern "C"' mechanism (take, for contrast, the piles of
nasty cruft needed to make things like JNI work).
a standing goal though is to get around to making it more symmetric, so
that the FFI transparently goes both ways (transparent C->BS calls, in
addition to transparent BS->C calls...).
yes... it also generally (mostly) works on raw pointers and C structs
and similar as well.
but, its drawbacks are that the implementation is notably far from being
"mature" (just how often do I have to debug things?...). and, as well, I
am probably the *only* person who uses it, so it doesn't have the same
sort of status or popularity as say, Java or Lua or Python or ...
(Python being IMO one of the few languages which would make me much
rather use Java instead...).
but, in this case, what is "best" likely depends more on personal
preferences and what one is doing with it, than any sort of empirical
measure.
or such...
Rui Maciel
> are you sure your langages are better than some type of macro-assembly?
I would say that all high level programming languages are macro-assembly
languages of sorts, varying in their level of abstraction and how their
macros are implemented and handled.
Rui Maciel
Kleuskes & Moos
> are you sure your langages are better than some type of macro-assembly?
They're certainly more convenient in many circumstances.
BGB
well, except that traditional macro-assemblers (say, MASM or TASM) are
more like "ASM with features", whereas HLLs generally work in terms of
some basic abstract computational model, with little/no direct
visibility into what is going on in the machine-level ISA.
for example, C represents a different conceptual model than does, for
example, an x86 assembler...
granted, yes, compilers do sort of resemble macro-transforms, except
that compilers usually use ASTs and free-form transformations (and often
various optimizations, ...), whereas traditional macro-expanders are
typically far more limited, usually only performing simple expansion and
substitution tasks.
also, most macro-expanders I have seen are single-stage (single pass or
multiple pass, and assembly is usually single-stage, although AFAICT
many assemblers use multiple passes for sake of compacting jumps and
similar), whereas typically compilers will use a chained set of
transformation stages, for example:
preprocessor;
parser (source -> AST);
front-end compiler (AST -> high-level IR);
middle-end compiler (high-level -> low-level IR);
back-end compiler (low-level IR -> ASM);
assembler;
...
or such...
BartC
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:4de0c923$0$16160$a729...@news.telepac.pt...
Not really. How would you implement this as a macro:
a=b;
And which of the hundreds of possible machine language sequences would it
end up as?
--
bartc
Uncle Steve
OO representations are a lot of work in C, but the language isn't
designed to make OO tasks convenient by way of some abbreviated
syntax. ASM is even worse. I enjoy using C for several reasons, not
the least of which is its near-asm performance with optimizing
compilers. The simple abstract numerical model of arithmetic in C
makes 99% of mathematical expressions simple to write, e.g.: a = b +
sqrt(c) -- no messy syntax. Input and output file operations are
convenient enough to use for scripting purposes, and in general the
C-library has everything you might need for 99% of the software you
might have to write.
ASM is non-portable by definition, so regardless of the size of your
macro-library, it's usefulness is tied to the life of the platform.
There must be tons of good code and algorithms lost forever because
they were written for a specific platform that was succeeded by
something with a different instruction set. C gets you just far
enough away from the hardware to make portability feasible, reducing
all that otherwise wasted effort.
Genetic programming or artificial intelligence research might not be
very nice to do in C, but for those problems we have OO languages, and
you really don't want macro assembler for that.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
Lorenzo Villari
Uncle Steve <stev...@gmail.com> wrote:
>
> Genetic programming or artificial intelligence research might not be
> very nice to do in C,
>
Why?
Uncle Steve
I haven't tried to, if that's what you're asking. I can just
sort-of envision what it is that AI programmers do from the little
literature I've skimmed, and I can't imagine doing that stuff in C.
I think you'd have to be a robot to do it successfully.
Rui Maciel
> Not really. How would you implement this as a macro:
>
> a=b;
What do you mean by a=b ?
Rui Maciel
Keith Thompson
I would say that you're ignoring the meaning of "macro-assembly".
A program in a macro-assembly language specifies (perhaps indirectly in
some cases) the CPU instructions to be generated. A program in a high
level language, including C, specifies behavior.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
BartC
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:4de140ad$0$16159$a729...@news.telepac.pt...
Assignment.
--
Bartc
Anders Wegge Keller
> are you sure your langages are better than some type of macro-assembly?
C is *portable* macro assembler, and little more. Now go and troll
somewhere else.
--
/Wegge
Leder efter redundant peering af dk.*,linux.debian.*
Angel
> "io_x" <a...@b.c.invalid> writes:
>
>> are you sure your langages are better than some type of macro-assembly?
>
> C is *portable* macro assembler, and little more. Now go and troll
> somewhere else.
C is fairly unique among programming languages in that it can be used
both at a very high abstract- and a very low machine level.
--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c
Keith Thompson
> "io_x" <a...@b.c.invalid> writes:
>> are you sure your langages are better than some type of macro-assembly?
>
> C is *portable* macro assembler, and little more. Now go and troll
> somewhere else.
No, C is not a macro assembler. Assembly language programs specify
CPU instructions. C programs specify behavior.
Keith Thompson
> On 2011-05-28, Anders Wegge Keller <we...@wegge.dk> wrote:
>> "io_x" <a...@b.c.invalid> writes:
>>
>>> are you sure your langages are better than some type of macro-assembly?
>>
>> C is *portable* macro assembler, and little more. Now go and troll
>> somewhere else.
>
> C is fairly unique among programming languages in that it can be used
> both at a very high abstract- and a very low machine level.
It's hardly unique in that respect. There are plenty of other languages
that can be used that way. (Ada is just one example.)
io_x
"Kleuskes & Moos" <kle...@xs4all.nl> ha scritto nel messaggio
news:99894fff-a46a-4940-a44b->4fb722...@h7g2000yqa.googlegroups.com...
On May 28, 9:08 am, "io_x" <a...@b.c.invalid> wrote:
>> are you sure your langages are better than some type of macro-assembly?
i'm not 100% sure
>They're certainly more convenient in many circumstances.
we speak of what we have seen,
from where came from your 100% cetain,
what do you have seen i not have seen
i confront code in the book i read
+ the code i see in NGs to the macro .asm i use
Rui Maciel
> I would say that you're ignoring the meaning of "macro-assembly".
>
> A program in a macro-assembly language specifies (perhaps indirectly in
> some cases) the CPU instructions to be generated. A program in a high
> level language, including C, specifies behavior.
...which also specifies the CPU instructions that are generated from the
source code, although it may not do that in a bijective way and it may
vary with the degree of abstraction. To put it differently, once you
recognize and accept the "indirectly" bit, the distinction between the
compiler of a macro language and the compiler of a high-level programming
language amounts to nit-picking regarding how much optimization it may or
may not employ, which is a discussion of how much grey is supposed to be
grey.
Rui Maciel
Rui Maciel
>> What do you mean by a=b ?
>
> Assignment.
Then you can translate this:
a = b
into this:
MOV eax, ebx
...minus any intermediate memory assignment which may be needed to manage
how memory is allocated.
Rui Maciel
James Kuyper
Sure, that's what a typical HLL compiler does. Except, of course, when
it converts it into an entirely different set of instructions, such as
would be appropriate if a and b are pointer types, or floating point, or
structures. BartC didn't mention this, but a=b can also involve implicit
conversions, depending upon the types of 'a' and 'b'. Finally, don't try
to gloss over the memory management details, either. Those also depend
upon the types of 'a' and 'b', and are also subject to considerable
rearrangement by an optimizer.
The type-dependent aspects of that translation require features that go
well beyond the capabilities of anything that can properly be called
only a macro assembler.
--
James Kuyper
James Kuyper
> Keith Thompson wrote:
>
>> I would say that you're ignoring the meaning of "macro-assembly".
>>
>> A program in a macro-assembly language specifies (perhaps indirectly in
>> some cases) the CPU instructions to be generated. A program in a high
>> level language, including C, specifies behavior.
>
> ...which also specifies the CPU instructions that are generated from the
> source code, although it may not do that in a bijective way and it may
> vary with the degree of abstraction.
I think that, by dropping bijectivity, you've also dropped the ability
to use the word "specifies". Standard C doesn't provide any method for
me to tell the compiler which "specific" instructions to use (though
many implementations provide the 'asm' statement as an extension). I can
only define the desired behavior, and the compiler is free to use any
set of instructions that produces that same behavior; there's nothing
"specific" about that relationship between the behavior and the
resulting set of instructions.
> ... To put it differently, once you
> recognize and accept the "indirectly" bit, the distinction between the
> compiler of a macro language and the compiler of a high-level programming
> language amounts to nit-picking regarding how much optimization it may or
> may not employ, which is a discussion of how much grey is supposed to be
> grey.
You can make any two things fit into the same category, by ignoring all
of the distinctions between them. However, a macro assembler not only
allows you to specify particular instructions; it requires you to do so.
An HLL compiler does neither. That's a pretty important distinction to
be ignoring. It is not a purely quantitative one, it's a very real
qualitative one.
--
James Kuyper
James Kuyper
> In article <irtea7$te3$1...@dont-email.me>, James Kuyper <james...@verizon.net>
>
>> The type-dependent aspects of that translation require features that go
>> well beyond the capabilities of anything that can properly be called
>> only a macro assembler.
>
Yes I have, but the last time I did so was more than two decades ago.
I'm willing to believe that modern ones have evolved into HLL languages
of their own; I'm not willing to believe that they can do those things,
and still qualify as nothing more than "macro assemblers". That would
require capabilities that go way beyond anything I'd be willing to refer
to as a "macro".
> ... With the proper macros you can do
> higher level programming than languages like C.
OK, please demonstrate the equivalent construct to "a=b", that handles
all of the type- and optimization-dependent issues that are implied by
that expression in C. Then please explain, for the benefit of those of
us who haven't used a modern macro assembler, how that construct works.
--
James Kuyper
io_x
"BGB" <cr8...@hotmail.com> ha scritto nel messaggio
news:irqgim$ll9$1...@news.albasani.net...
> On 5/28/2011 12:08 AM, io_x wrote:
>
> now, as for C vs C++, or something being "universally better", I don't
> personally believe any such "universal betterness" exists.
instead it exist
BartC
news:chine.bleu-649E4...@news.eternal-september.org...
> In article <irtgi5$bnj$1...@dont-email.me>, James Kuyper
> <james...@verizon.net>
> wrote:
> Actually I was thinking in terms of Cyber 170 COMPASS or Cyber 205 META.
> You
> could also do it with m4.
Those all seem to be around 30 years old.
If such a macro language can execute any algorithm, I suppose you could just
give it a file containing C syntax, and it produces the requisite object
files (or whatever target form is desired).
But then it's just an implementation language for a C compiler.
Of more interest would be how to write C code in the macro language itself,
where it would be expected that conventional C syntax would give some
problems (which bit of "a=b;" is the name of the macro?).
I suppose if you discarded syntax, and just wrote assign(a,b) or (assign a
b), then the use of macro language might start to be more viable, but it
still seems a lot more complicated than just writing a dedicated compiler.
And HLL users like their syntax!
--
Bartc
Keith Thompson
Oh, did we mention that a and b are both multi-kilobyte structures?
And that the target CPU doesn't have a MOV instruction?
Keith Thompson
> In article <irtea7$te3$1...@dont-email.me>, James Kuyper
> <james...@verizon.net> wrote:
>
>> The type-dependent aspects of that translation require features that go
>> well beyond the capabilities of anything that can properly be called
>> only a macro assembler.
>
> can do higher level programming than languages like C.
But if these macros are really macros, then they're still specifying
sequences of instructions. Perhaps a single macro invocation will
result in, say, 1000 instructions being generated, with variations
based on the arguments, but the point is that you can determine
*which* 1000 instructions they are by analyzing the assembly
source code.
*That's* the difference between an assembler and a compiler.
An assembler generates a sequence of CPU instructions specified by
its input. A compiler generates a sequence of CPU instructions
(or perhaps some higher-level form) that results in the behavior
specified by its input.
There are certainly plenty of ways in which C is a lower level
language than some others. Other languages have direct support
for various abstractions that C lacks. But that doesn't make C
some kind of high-level assembler, just a relatively low-level
compiled language.
There's no point in continuing to use words like "assembler" and
"compiler" if we forget what they actually mean.
Seebs
> ...which also specifies the CPU instructions that are generated from the
> source code, although it may not do that in a bijective way and it may
> vary with the degree of abstraction. To put it differently, once you
> recognize and accept the "indirectly" bit, the distinction between the
> compiler of a macro language and the compiler of a high-level programming
> language amounts to nit-picking regarding how much optimization it may or
> may not employ, which is a discussion of how much grey is supposed to be
> grey.
I don't think I buy that. Macro assemblers are still fundamentally
manipulating stuff which is basically tied to the CPU architecture. Whether
the machine has one general purpose register or 128 will affect the code
you write.
-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
Rui Maciel
> I don't think I buy that. Macro assemblers are still fundamentally
> manipulating stuff which is basically tied to the CPU architecture.
> Whether the machine has one general purpose register or 128 will affect
> the code you write.
Let's put it this way: we develop a C compiler which performs no
optimization whatsoever and therefore is able to bijectively map C code to
code in any other lower level language, which may be an assembly language
or even object code. If that map only covers a specific CPU architecture,
and therefore it is basically tied to that particular CPU architecture,
does that mean that this particular hypothetical compiler is a macro
assembler?
Rui Maciel
Rui Maciel
> Which CPU instructions, then, are specified by the program
>
> #include <stdio.h>
> int main( void ){ printf( "hello, world" ); }
call printf
...provided that the calling conversion is met.
Rui Maciel
Michael Press
Rui Maciel <rui.m...@gmail.com> wrote:
The author of a program for a macro assembler
knows exactly what machine instructions will be
produced from his program. This is not the
case for the author of a C program.
--
Michael Press
Rui Maciel
> The author of a program for a macro assembler
> knows exactly what machine instructions will be
> produced from his program.
If he uses macros, either pre-defined ones or macros which he didn't
write, then he doesn't know what machine instructions will be produced by
his program. If he compiles his assembly code with a compiler which
performs any form of code optimization then he doesn't know what machine
instructions will be produced by his program. And yet, the language never
ceassed to be assembly.
Conversely, if we have a compiler which bijectively maps C code to object
code and if a programmer writes C code with that particular compiler in
mind then he is able to know exactly what assembly code will be generated
from his code. And yet, the language never ceassed to be C.
> This is not the
> case for the author of a C program.
As I've demonstrated above, it can be the case for the author of an C
program and it may not be the case for the author of an assembly program.
The compiler isn't the language and the language isn't the compiler.
Rui Maciel
Rui Maciel
> I think that, by dropping bijectivity, you've also dropped the ability
> to use the word "specifies". Standard C doesn't provide any method for
> me to tell the compiler which "specific" instructions to use (though
> many implementations provide the 'asm' statement as an extension).
This is irrelevant. If you compile your code with a compiler which
doesn't perform any optimization whatsoever and is able to bijectively map
C code to object code then, although the standard doesn't specify anything
regarding this, you are able to tell exactly what object code you are
generating from a set of C statements. This means that you are able to
tell the compiler exactly which instructions to dump. It may not be as
expressive as using an assembly language but you are still specifying what
object code should be dumped.
> I can
> only define the desired behavior, and the compiler is free to use any
> set of instructions that produces that same behavior; there's nothing
> "specific" about that relationship between the behavior and the
> resulting set of instructions.
If you write code using an assembly language which supports macros and you
write your code based on those macros (and therefore you would be writing
your assembly code by defining desired behaviour instead of specific
instructions) then would that mean that this macro-assembly language is
suddenly not a macro-assemblly language anymore?
> You can make any two things fit into the same category, by ignoring all
> of the distinctions between them. However, a macro assembler not only
> allows you to specify particular instructions; it requires you to do so.
If you happen to use a pre-defined macro on a program written in a
assembly language then how exactly were you required to specify those
instructions? And if you develop a program in assembly based on macros
which you didn't develop yourself nor you want to waste your time checking
then does that mean that that particular macro-assembly language isn't a
macro-assembly language? And if you have a bijective map between C code
and object code then will the ability to specify exactly which set of
instructions your code generates make the C programming language a macro-
assembly language?
Knowing this, there is a reason why they are placed in the same category.
You need to intentionally ignore the fundamental definition of that
category to be unable to include them in it.
> An HLL compiler does neither. That's a pretty important distinction to
> be ignoring. It is not a purely quantitative one, it's a very real
> qualitative one.
You are confusing the compiler with the language and the language with the
compiler, which may explain your confusion regarding this subject. To
clear this for you, answer this: if I compile assembly code with a
compiler which performs any form of optimization (and therefore we lose
the ability to "specify particular instructions") then does that mean that
that particular assembly language ceasses to be an assembly language? And
if we compile C code with a compiler which doesn't perform any
optimization and bijectively maps C code to object code then, by using
expressions which we know are mapped to single instructions (for example,
i++) then would that mean that C is suddenly an assembly language? And
would that mean that the level of a particular programming language
depends on the amount of optimization that it employs?
Rui Maciel
Rui Maciel
> Sure, that's what a typical HLL compiler does. Except, of course, when
> it converts it into an entirely different set of instructions, such as
> would be appropriate if a and b are pointer types, or floating point, or
> structures. BartC didn't mention this, but a=b can also involve implicit
> conversions, depending upon the types of 'a' and 'b'. Finally, don't try
> to gloss over the memory management details, either. Those also depend
> upon the types of 'a' and 'b', and are also subject to considerable
> rearrangement by an optimizer.
As soon as a variable is declared, those details are all covered.
> The type-dependent aspects of that translation require features that go
> well beyond the capabilities of anything that can properly be called
> only a macro assembler.
Why do you believe that? Do you believe that calling convensions are also
features which go well beyond the capabilities of anything that can be
called a assembler, let alone one which supports macros? And do you also
believe that if a compiler for an assembly language performs the most
rudimentary optimization then it would force that language to be something
other than an assembly language?
Again, it appears that there is some confusion regarding what a language
is and what the compiler does.
Rui Maciel
Rui Maciel
> Oh, did we mention that a and b are both multi-kilobyte structures?
> And that the target CPU doesn't have a MOV instruction?
Would that made it impossible to generate assembly code for those cases?
Rui Maciel
Rui Maciel
> On 05/29/2011 08:37 AM, China Blue Angels wrote:
>> In article <irtea7$te3$1...@dont-email.me>, James Kuyper
>> <james...@verizon.net> wrote:
>>
>>> The type-dependent aspects of that translation require features that
>>> go well beyond the capabilities of anything that can properly be
>>> called only a macro assembler.
>>
>> You haven't used a proper macro assembler.
>
> Yes I have, but the last time I did so was more than two decades ago.
> I'm willing to believe that modern ones have evolved into HLL languages
> of their own; I'm not willing to believe that they can do those things,
> and still qualify as nothing more than "macro assemblers". That would
> require capabilities that go way beyond anything I'd be willing to refer
> to as a "macro".
You either classify the language or the compiler. You can't claim that
language A is or isn't language A if you compile a strictly conforming
program with compiler X or with compiler Y.
>> ... With the proper macros you can do
>> higher level programming than languages like C.
>
> OK, please demonstrate the equivalent construct to "a=b", that handles
> all of the type- and optimization-dependent issues that are implied by
> that expression in C. Then please explain, for the benefit of those of
> us who haven't used a modern macro assembler, how that construct works.
Do you actually believe that it is impossible to convert C code to object
code?
Rui Maciel
Rui Maciel
> But if these macros are really macros, then they're still specifying
> sequences of instructions. Perhaps a single macro invocation will
> result in, say, 1000 instructions being generated, with variations
> based on the arguments, but the point is that you can determine
> *which* 1000 instructions they are by analyzing the assembly
> source code.
You can say the exact same thing about a basic C compiler which performs
no optimization whatsoever, which incidentally is the point I'm making.
> *That's* the difference between an assembler and a compiler.
> An assembler generates a sequence of CPU instructions specified by
> its input. A compiler generates a sequence of CPU instructions
> (or perhaps some higher-level form) that results in the behavior
> specified by its input.
Once you use macros in an assembly program you also start generating
sequence of CPU instructions that result in the behaviour specified by its
imput. Once you compile assembly code with any optimization then you stop
specifying what you want to get and instead you specify what you mean.
And the level of a programming language doesn't depend on what compilers
are used.
> There are certainly plenty of ways in which C is a lower level
> language than some others. Other languages have direct support
> for various abstractions that C lacks. But that doesn't make C
> some kind of high-level assembler, just a relatively low-level
> compiled language.
Here we are, debating what shade of grey is the true grey and what shade
of grey isn't grey.
> There's no point in continuing to use words like "assembler" and
> "compiler" if we forget what they actually mean.
We either discuss programming languages or we discuss compilers. A
language doesn't depend on what compiler is employed.
Rui Maciel
Seebs
> Conversely, if we have a compiler which bijectively maps C code to object
> code and if a programmer writes C code with that particular compiler in
> mind then he is able to know exactly what assembly code will be generated
> from his code. And yet, the language never ceassed to be C.
I think the difference is that the C program's meaning can be understood
without any reference to the targeted processor.
> As I've demonstrated above, it can be the case for the author of an C
> program and it may not be the case for the author of an assembly program.
Doesn't matter what a specific author knows; what matters is what the
code specifies. The C program is still the same program fed to a different
compiler for a different architecture.
Seebs
No.
So far as I can tell, the essential definition of "an assembler" is that
code is written in terms of processor registers and instructions; you can
have text-replacement rules and such, but fundamentally the developer is
thinking about, and has direct access to, that layer of the system.
James Kuyper
> James Kuyper wrote:
>
>> On 05/29/2011 08:37 AM, China Blue Angels wrote:
>>> You haven't used a proper macro assembler.
>>
>> Yes I have, but the last time I did so was more than two decades ago.
>> I'm willing to believe that modern ones have evolved into HLL languages
>> of their own; I'm not willing to believe that they can do those things,
>> and still qualify as nothing more than "macro assemblers". That would
>> require capabilities that go way beyond anything I'd be willing to refer
>> to as a "macro".
>
> You either classify the language or the compiler. You can't claim that
> language A is or isn't language A if you compile a strictly conforming
> program with compiler X or with compiler Y.
I have no idea what you're getting on about.
>>> ... With the proper macros you can do
>>> higher level programming than languages like C.
>>
>> OK, please demonstrate the equivalent construct to "a=b", that handles
>> all of the type- and optimization-dependent issues that are implied by
>> that expression in C. Then please explain, for the benefit of those of
>> us who haven't used a modern macro assembler, how that construct works.
>
> Do you actually believe that it is impossible to convert C code to object
> code?
No, C compilers do that routinely, so it is patently not impossible. I'm
only saying that such a conversion, in it's full generality, requires
capabilities that go way beyond the concept of a "macro". There may
indeed be things nowadays that go by the name "macro assembler" which
have such capabilities; but if so, they represent an evolution of the
term beyond it's original meaning.
--
James Kuyper
James Kuyper
> James Kuyper wrote:
>
>> I think that, by dropping bijectivity, you've also dropped the ability
>> to use the word "specifies". Standard C doesn't provide any method for
>> me to tell the compiler which "specific" instructions to use (though
>> many implementations provide the 'asm' statement as an extension).
>
> This is irrelevant. If you compile your code with a compiler which
> doesn't perform any optimization whatsoever and is able to bijectively map
> C code to object code then, although the standard doesn't specify anything
> regarding this, you are able to tell exactly what object code you are
> generating from a set of C statements.
True: for most compilers, the combination of a specific piece of source
code, the specific compiler, and the specific set of compiler options,
does uniquely determine the sequence of instructions to be generated.
However, that's also irrelevant to point being made. The source code
alone does NOT determine which instructions will be generated, you need
to combine it with a specific compiler to get that result. A different
compiler, or even the same compiler with different options specified,
can produce different instructions without in any way failing to conform
to the requirements of the C standard.
In contrast, the input given to a macro assembler uniquely determines
the output; if two macro assemblers which supposedly implement the same
macro assembly language produce different outputs, then one of them is
implementing it incorrectly. At least, that's my experience, outdated
though it might be; if that's no longer true of the more modern ones
that I haven't used, then I would question the accuracy of their
description as mere "macro assemblers".
>> I can
>> only define the desired behavior, and the compiler is free to use any
>> set of instructions that produces that same behavior; there's nothing
>> "specific" about that relationship between the behavior and the
>> resulting set of instructions.
>
> If you write code using an assembly language which supports macros and you
> write your code based on those macros (and therefore you would be writing
> your assembly code by defining desired behaviour instead of specific
> instructions) then would that mean that this macro-assembly language is
> suddenly not a macro-assemblly language anymore?
The macros I'm familiar with did NOT specify behavior. They merely
provided a more compact way of requesting generation of a long but
precisely specified sequence of instructions.
If more modern macro languages provide a feature that allows you to
specify only the behavior, leaving the assembler free to choose between
multiple different, but all equally valid, ways of implementing that
behavior, then I would no long consider it appropriate to call them macros.
>> You can make any two things fit into the same category, by ignoring all
>> of the distinctions between them. However, a macro assembler not only
>> allows you to specify particular instructions; it requires you to do so.
>
> If you happen to use a pre-defined macro on a program written in a
> assembly language then how exactly were you required to specify those
> instructions?
By invoking that macro, rather than another.
> ... And if you develop a program in assembly based on macros
> which you didn't develop yourself nor you want to waste your time checking
> then does that mean that that particular macro-assembly language isn't a
> macro-assembly language?
If, when a given macro invoked in a specific manner, in a specific
context, the assembler has the freedom to choose between multiple
different but equally valid sequences of instructions to generate, then
yes, I think it can no longer be described as merely a macro assembler.
> ... And if you have a bijective map between C code
> and object code then will the ability to specify exactly which set of
> instructions your code generates make the C programming language a macro-
> assembly language?
If that bijective map is uniquely determined across all implementations
of C (which would very seriously restrict the portability of C), then
yes, it would convert C into not much more than a macro-assembly language.
>> An HLL compiler does neither. That's a pretty important distinction to
>> be ignoring. It is not a purely quantitative one, it's a very real
>> qualitative one.
>
> You are confusing the compiler with the language and the language with the
> compiler, which may explain your confusion regarding this subject. To
> clear this for you, answer this: if I compile assembly code with a
> compiler which performs any form of optimization (and therefore we lose
> the ability to "specify particular instructions") then does that mean that
> that particular assembly language ceases to be an assembly language?
No. But the thing that interprets it ceases to be purely macro-based, as
I understand the term.
> ... And
> if we compile C code with a compiler which doesn't perform any
> optimization and bijectively maps C code to object code then, by using
> expressions which we know are mapped to single instructions (for example,
> i++) then would that mean that C is suddenly an assembly language?
Most C compilers define such a bijective mapping. That's true separately
at each level of optimization, and not merely when optimization is
turned off. However, its a different map at different optimization
levels, it's a different map when different options are turned on, and
it's a different map for different compilers. Yet, many (though
generally not all) of those different maps would allow the compiler to
be conforming; and that's part of what makes it a high level language.
More directly to the point, a C compiler that chose randomly, rather
than deterministically, between different valid ways of implementing a
given C construct, could still be fully conforming to the C standard.
> ... And
> would that mean that the level of a particular programming language
> depends on the amount of optimization that it employs?
No, not at all. The fact that the same compiler could remain fully
conforming to the same language specification at multiple different
optimization levels, is part of what makes the language so-specified a
high level language. The fact that compilers which target many different
platforms with wildly different instruction sets can also conform to the
same language specification is another part of it. Any macro assembler
language with at least some of those same capabilities (which may very
well be the case, since my experience is out of date) has evolved beyond
being merely a macro assembler, and has become at least a slightly
higher-level language.
--
James Kuyper
BartC
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:4de43da3$0$16782$a729...@news.telepac.pt...
I suspect half the people here haven't a clue what you're getting at.
Obviously there are ways of getting from a=b; to all the myriad possible
machine codes.
Are you arguing that instead of using a software customised to a language to
do that (a compiler) you can do it with a general purpose software, a
macro-assembler?
Then they are just different approaches to the same aim, without it being
clear what the advantages of the macro-language might be.
But we still haven't seen an actual example of a macro to do a=b! Perhaps
you're just theorising?
--
Bartc
Angel
Not impossible, it just requires more and different instructions. The
old 6510 processor, for example, didn't have a MOV instruction, but it
did have LDA/STA instructions which can have a similar effect.
A program written in standard C will behave the same whether it is
compiled on x86, amd64, sparc or ppc (not entirely true, I know, but in
an ideal situation) while the same program written in assembler will
work only on the architecture it was written for.
--
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c
Rui Maciel
<snip/>
> A program written in standard C will behave the same whether it is
> compiled on x86, amd64, sparc or ppc (not entirely true, I know, but in
> an ideal situation) while the same program written in assembler will
> work only on the architecture it was written for.
If you compile a C compiler with a compiler that only supports a single
architecture then that particular program, compiled by that compiler, will
work only on that architecture. Conversely, if you compile an assembly
program with a compiler which just so happens to support other
architectures, whether by transliterating or by using some sort of
intermediate form, then that program written in assembly will behave the
same whether it is compiled for any architecture which is supported by the
compiler.
That is, what the language is and what the compiler does are two different
and completely distinct things.
Rui Maciel
Seebs
> architecture then that particular program, compiled by that compiler, will
> work only on that architecture.
But "compiled by that compiler" is not an attribute of the program, it's
a thing you did to it. The program can be compiled with other compilers.
An assembler will, at some fundamental level, let you do things that
refer to specific registers, and that ties you to machines that have those
registers.
Rui Maciel
> ISO/IEC 9899:1999 (E) does nowhere specify that this code
> has to be generated. Any other code that behaves /as-if/
> is as well, like »fputs( "hello, world", stdout )«.
>
> A macro assembler allows you to /enforce/ a specific
> machine instruction.
In this case it's irrelevant what the C standard specifies and doesn't
specify. For example, are you aware of any standard on any assembly
language which specifies which code has to be generated from any given
instruction?
Rui Maciel
Keith Thompson
In the very narrowly contrived circumstances you postulate, the
programmer is using a superset of C which, in addition to specifying
the behavior of a C program, also specifies the CPU instructions to
be used to achieve that behavior. This might reasonably be thought
of as an unusually high-level macro assembler.
If, on the other hand, the compiler can choose to generate a
different instruction sequence while still being considered correct
(say, by performing operations in a different order), then it's
just a C compiler, not an assembler.
Optimizing assemblers might be an interesting border case.
I've never used such a thing, but I presume that the input program
specifies (directly or indirectly) a specific instruction sequence,
and the output is an instruction sequence with the same run-time
behavior. This has very little to do with C.
There's a big difference between assemblers and compilers. In some
cases, the line between them can be a bit blurry. Why are you
trying to erase it?
Keith Thompson
> Michael Press wrote:
>> The author of a program for a macro assembler
>> knows exactly what machine instructions will be
>> produced from his program.
>
> If he uses macros, either pre-defined ones or macros which he didn't
> write, then he doesn't know what machine instructions will be produced by
> his program.
But he can find out easily enough.
If I'm writing an assembly program, I don't need to know the op code for
the MOV instruction. If I do happen to know it, that doesn't mean I'm
now writing machine code; I'm still writing assembly code.
> If he compiles his assembly code with a compiler which
> performs any form of code optimization then he doesn't know what machine
> instructions will be produced by his program. And yet, the language never
> ceassed to be assembly.
The input language ceased to be assembly when it stopped specifying
CPU instructions.
[...]
Keith Thompson
No, of course not. It merely means that it would generate *different*
assembly code. The C language input doesn't specify which assembly code
is generated.
The output is assembly code; the input is not.
Keith Thompson
> Keith Thompson wrote:
>> But if these macros are really macros, then they're still specifying
>> sequences of instructions. Perhaps a single macro invocation will
>> result in, say, 1000 instructions being generated, with variations
>> based on the arguments, but the point is that you can determine
>> *which* 1000 instructions they are by analyzing the assembly
>> source code.
>
> You can say the exact same thing about a basic C compiler which performs
> no optimization whatsoever, which incidentally is the point I'm making.
We obviously have very different ideas about the difference between
an assembler and a compiler, and between assembly code and high
level language code (with C being considered "high level" for the
current purposes).
I've stated here what I think the difference is. Assembly code
specifies instructions; C code specifies behavior.
What do you think the difference is? Or if you don't think there
is a difference, why do we use two different words?
Is there *any* programming language (at or above the level of C)
that you don't consider to be a macro assembler?
Keith Thompson
> James Kuyper wrote:
[...]
>> OK, please demonstrate the equivalent construct to "a=b", that handles
>> all of the type- and optimization-dependent issues that are implied by
>> that expression in C. Then please explain, for the benefit of those of
>> us who haven't used a modern macro assembler, how that construct works.
>
> Do you actually believe that it is impossible to convert C code to object
> code?
Nobody has made such an absurd suggestion. The fact that you ask that
question indicates to me that you've misunderstood the points the rest
of us are trying to make.
Of course it's possible to convert C code to object code. That doesn't
make C an assembler.
Keith Thompson
[...]
> You really should learn more about macros and other text preprocessing for
> program sources. For example with something akin to sed, I can write a¾b instead
> a<=b. Unicode has been available for years, but programmers are still stuck in
> an ASCII only desert.
That came across as a 3/4 symbol (0xBE, Unicode "VULGAR FRACTION
THREE QUARTERS"). I presume you were aiming for 0x2264, "LESS-THAN
OR EQUAL TO". There was nothing in your article's headers to
indicate what encoding it's using.
Yes, Unicode is available, but setting up an environment with a
universally agreed representation is still non-trivial. I'd love to be
able to assume that all text files are UTF-8 unless otherwise specified,
but that's not yet possible. (Windows still insists on using UTF-16
rather than UTF-8, for example.)
And my keyboard has '<' and '=' keys, but it doesn't have a
'≤' key.
Keith Thompson
> Stefan Ram wrote:
>> ISO/IEC 9899:1999 (E) does nowhere specify that this code
>> has to be generated. Any other code that behaves /as-if/
>> is as well, like »fputs( "hello, world", stdout )«.
>>
>> A macro assembler allows you to /enforce/ a specific
>> machine instruction.
>
> In this case it's irrelevant what the C standard specifies and doesn't
> specify.
It's entirely relevant to the point most of us are trying to discuss.
> For example, are you aware of any standard on any assembly
> language which specifies which code has to be generated from any given
> instruction?
It's been a long time, but I thought that was the whole point of
assembly language: it specifies the machine language instructions
to be generated. Has the meaning of the term changed that much?
If so, what does it mean now?
Angel
> architecture then that particular program, compiled by that compiler, will
> work only on that architecture. Conversely, if you compile an assembly
> program with a compiler which just so happens to support other
> architectures, whether by transliterating or by using some sort of
> intermediate form, then that program written in assembly will behave the
> same whether it is compiled for any architecture which is supported by the
> compiler.
>
> That is, what the language is and what the compiler does are two different
> and completely distinct things.
This is "hello world" in C:
#include <stdio.h>
int main(void)
{
printf("Hello world!\n");
}
It will work without modification on virtually any architecture with a
reasonably standards-compliant C compiler.
Now here is the same "hello world" in assembler:
.file "hello.c"
.section .rodata
.LC0:
.string "Hello world!"
.text
.globl main
.type main, @function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
movq %rsp, %rbp
.cfi_offset 6, -16
.cfi_def_cfa_register 6
movl $.LC0, %edi
call puts
leave
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5"
.section .note.GNU-stack,"",@progbits
Let's see you get it to work on something that isn't x86 or compatible,
without changing a letter of the program.
Here is, for example, the result on a Sparc64:
gcc -o hello hello.s
hello.s: Assembler messages:
hello.s:11: Error: Unknown opcode: `pushq'
hello.s:13: Error: Unknown opcode: `movq'
hello.s:16: Error: Illegal operands
hello.s:18: Error: Unknown opcode: `leave'
Now imagine how the situation for a non-trivial program would be.
Michael Press
Rui Maciel <rui.m...@gmail.com> wrote:
> Michael Press wrote:
>
> > The author of a program for a macro assembler
> > knows exactly what machine instructions will be
> > produced from his program.
>
> If he uses macros, either pre-defined ones or macros which he didn't
> write, then he doesn't know what machine instructions will be produced by
> his program. If he compiles his assembly code with a compiler which
> performs any form of code optimization then he doesn't know what machine
Assembly code is not compiled, it is assembled.
> instructions will be produced by his program. And yet, the language never
> ceassed to be assembly.
>
> Conversely, if we have a compiler which bijectively maps C code to object
> code and if a programmer writes C code with that particular compiler in
> mind then he is able to know exactly what assembly code will be generated
> from his code. And yet, the language never ceassed to be C.
We cannot specify machine instructions with C code.
> > This is not the
> > case for the author of a C program.
>
> As I've demonstrated above, it can be the case for the author of an C
> program and it may not be the case for the author of an assembly program.
> The compiler isn't the language and the language isn't the compiler.
I cannot follow this argument.
--
Michael Press
Rui Maciel
> In the very narrowly contrived circumstances you postulate, the
> programmer is using a superset of C which, in addition to specifying
> the behavior of a C program, also specifies the CPU instructions to
> be used to achieve that behavior. This might reasonably be thought
> of as an unusually high-level macro assembler.
>
> If, on the other hand, the compiler can choose to generate a
> different instruction sequence while still being considered correct
> (say, by performing operations in a different order), then it's
> just a C compiler, not an assembler.
Notice that you are referring to compilers, and not to programming
language. Therefore, you can make the exact same claim regarding assembly
languages and the compilers which are employed to map the source code to
object code. That is, if an assembly compiler is able to generate a
different instruction sequence while being considered correct (i.e.,
perform any form of optimization) then, from your observation, we wouldn't
be dealing with an assembly language anymore. And that's a paradox.
> Optimizing assemblers might be an interesting border case.
> I've never used such a thing, but I presume that the input program
> specifies (directly or indirectly) a specific instruction sequence,
> and the output is an instruction sequence with the same run-time
> behavior. This has very little to do with C.
Yes, but it also happens to be the topic of this thread: that all high
level programming languages are macro-assembly languages of sorts, varying
in their level of abstraction and how their macros are implemented and
handled.
> There's a big difference between assemblers and compilers. In some
> cases, the line between them can be a bit blurry. Why are you
> trying to erase it?
I'm not erasing that line, mainly because it never actually existed to
begin with. The colloquial definitions which are frequently attributed to
assembly languages aren't based on any properties of those languages.
Instead, those definitions are based on assumptions regarding the
capabilities of specific compilers (while ignoring others) which so happen
to support those languages. Other than this, the issue regarding the
different level of abstraction which is employed by different programming
languages also can't be separated with a clear line.
Rui Maciel
James Kuyper
...
> object code. That is, if an assembly compiler is able to generate a
> different instruction sequence while being considered correct (i.e.,
> perform any form of optimization) then, from your observation, we wouldn't
> be dealing with an assembly language anymore. And that's a paradox.
You haven't demonstrated any paradox yet. It ceased to be an assembly
language from the moment it's specification was written in such a form
as to allow creation of such a compiler; creating the compiler merely
demonstrates that fact.
--
James Kuyper
Rui Maciel
> In article <4de43d29$0$16782$a729...@news.telepac.pt>,
> Rui Maciel <rui.m...@gmail.com> wrote:
>
>> Michael Press wrote:
>>
>> > The author of a program for a macro assembler
>> > knows exactly what machine instructions will be
>> > produced from his program.
>>
>> If he uses macros, either pre-defined ones or macros which he didn't
>> write, then he doesn't know what machine instructions will be produced
>> by
>> his program. If he compiles his assembly code with a compiler which
>> performs any form of code optimization then he doesn't know what
>> machine
>
> Assembly code is not compiled, it is assembled.
Please define "compiled".
>> instructions will be produced by his program. And yet, the language
>> never ceassed to be assembly.
>>
>> Conversely, if we have a compiler which bijectively maps C code to
>> object code and if a programmer writes C code with that particular
>> compiler in mind then he is able to know exactly what assembly code
>> will be generated
>> from his code. And yet, the language never ceassed to be C.
>
> We cannot specify machine instructions with C code.
If you happen to compile your code with a compiler which bijectively maps
C code to object code then how exactly would you be unable to specify
which set of instructions would be generated?
Conversely, if you compile an assembly program with a compiler which
performs some sort of optimization, and therefore you are unable to know,
let alone specify which machine instructions are generated, then would
that mean that your assembly language would from that moment on ceasse
being an assembly language? And would that mean that the very fundamental
nature of your programming language would depend on what compiler you
choosed to use? Obviously, no.
>> > This is not the
>> > case for the author of a C program.
>>
>> As I've demonstrated above, it can be the case for the author of an C
>> program and it may not be the case for the author of an assembly
>> program. The compiler isn't the language and the language isn't the
>> compiler.
>
> I cannot follow this argument.
You can always read the thread.
Rui Maciel
James Kuyper
> Michael Press wrote:
>
>> In article <4de43d29$0$16782$a729...@news.telepac.pt>,
>> Rui Maciel <rui.m...@gmail.com> wrote:
>>> As I've demonstrated above, it can be the case for the author of an C
>>> program and it may not be the case for the author of an assembly
>>> program. The compiler isn't the language and the language isn't the
>>> compiler.
>>
>> I cannot follow this argument.
>
> You can always read the thread.
That wouldn't help - the argument still doesn't make sense.
--
James Kuyper
Rui Maciel
> But "compiled by that compiler" is not an attribute of the program, it's
> a thing you did to it. The program can be compiled with other
> compilers.
Exactly. What the language is and what a compiler does are two very
different things. Therefore, it doesn't make sense to try to classify a
particular programming language based on the features of a partcular
compiler. After all, and as you said, the program can be compiled with
other compilers.
> An assembler will, at some fundamental level, let you do things that
> refer to specific registers, and that ties you to machines that have
> those registers.
Well, it will tie someone to a particular machine until someone invests
his time developing a compiler which is able to abstract that and, by
doing that, support other machines. After all, the language isn't the
compiler and the compiler isn't the language.
Rui Maciel
Rui Maciel
> Rui Maciel <rui.m...@gmail.com> writes:
>> Stefan Ram wrote:
>>> ISO/IEC 9899:1999 (E) does nowhere specify that this code
>>> has to be generated. Any other code that behaves /as-if/
>>> is as well, like »fputs( "hello, world", stdout )«.
>>>
>>> A macro assembler allows you to /enforce/ a specific
>>> machine instruction.
>>
>> In this case it's irrelevant what the C standard specifies and doesn't
>> specify.
>
> It's entirely relevant to the point most of us are trying to discuss.
The issue being discussed is that all high level programming languages are
macro-assembly languages of sorts. No one is arguing that all languages
employ the same level of abstraction. Therefore, the level of abstraction
provided by the C programming language, and how it compares with other
languages, is irrelevant.
Adding to this, I'm not aware of a single assembly language which
"enforces" specific machine instructions. Assembly languages may provide
the user with a way to state what opcode they wish to use and where they
wish to use it. Yet, nothing forces a compiler to obey that request, and
any compiler writer is free to add some form of optimization that is able
to generate a completely different set of opcodes. This applies to all
languages, including any assembly language and C.
>> For example, are you aware of any standard on any assembly
>> language which specifies which code has to be generated from any given
>> instruction?
>
> It's been a long time, but I thought that was the whole point of
> assembly language: it specifies the machine language instructions
> to be generated. Has the meaning of the term changed that much?
> If so, what does it mean now?
No one is arguing that assembly languages employ a lower level of
abstraction. Yet, this doesn't change their fundamental nature as a
programming language, nor does it mean that their nature is any different
than other programming languages, such as C. In any case we are dealing
with languages which let the programmer specify sequences of instructions.
The language doesn't change with the way a particular compiler maps those
instruction sequences to sets of opcodes.
Rui Maciel
Rui Maciel
You've presented a compiler error caused by an attempt to compile code
which wasn't supported by that compiler. If I try to compile Pascal code
with gcc I will also get a bunch of error messages. Yet, that doesn't
mean that it isn't possible to compile Pascal code on your platform.
If, instead, you tried to compile it with a compiler which supported that
programming language then obviously it would work. This applies to both
the Pascal Vs C example and your x86 Vs Sparc64 example.
Rui Maciel
Keith Thompson
> Keith Thompson wrote:
>> Rui Maciel <rui.m...@gmail.com> writes:
>>> Stefan Ram wrote:
>>>> ISO/IEC 9899:1999 (E) does nowhere specify that this code
>>>> has to be generated. Any other code that behaves /as-if/
>>>> is as well, like »fputs( "hello, world", stdout )«.
>>>>
>>>> A macro assembler allows you to /enforce/ a specific
>>>> machine instruction.
>>>
>>> In this case it's irrelevant what the C standard specifies and doesn't
>>> specify.
>>
>> It's entirely relevant to the point most of us are trying to discuss.
>
> The issue being discussed is that all high level programming languages are
> macro-assembly languages of sorts. No one is arguing that all languages
> employ the same level of abstraction. Therefore, the level of abstraction
> provided by the C programming language, and how it compares with other
> languages, is irrelevant.
>
> Adding to this, I'm not aware of a single assembly language which
> "enforces" specific machine instructions. Assembly languages may provide
> the user with a way to state what opcode they wish to use and where they
> wish to use it. Yet, nothing forces a compiler to obey that request, and
> any compiler writer is free to add some form of optimization that is able
> to generate a completely different set of opcodes. This applies to all
> languages, including any assembly language and C.
Then things must have changed a lot more than I was aware of. In my
experience (which admittedly is fairly old), *all* assembly languages
specify exactly which machine instructions are to be generated; that's
the whole point of an assembly language.
Here's a small assembly language program (it's gcc's output for a
"hello, world" C program):
.file "hello.c"
.section .rodata
.LC0:
.string "Hello, world"
.text
.globl main
.type main, @function
main:
pushl %ebp
movl %esp, %ebp
andl $-16, %esp
subl $16, %esp
movl $.LC0, (%esp)
call puts
movl $0, %eax
leave
ret
.size main, .-main
.ident "GCC: (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2"
.section .note.GNU-stack,"",@progbits
If I ran that through an assembler and got something other than
a pushl instruction, followed by a movl instruction, followed by
an andl instruction, etc., I would conclude either that I'm using
a broken assembler, or that I'm using something that's more than
just an assembler.
>>> For example, are you aware of any standard on any assembly
>>> language which specifies which code has to be generated from any given
>>> instruction?
>>
>> It's been a long time, but I thought that was the whole point of
>> assembly language: it specifies the machine language instructions
>> to be generated. Has the meaning of the term changed that much?
>> If so, what does it mean now?
>
> No one is arguing that assembly languages employ a lower level of
> abstraction. Yet, this doesn't change their fundamental nature as a
> programming language, nor does it mean that their nature is any different
> than other programming languages, such as C. In any case we are dealing
> with languages which let the programmer specify sequences of instructions.
> The language doesn't change with the way a particular compiler maps those
> instruction sequences to sets of opcodes.
Was that intended to be an answer to my question? I wasn't asking about
levels of absraction. My question was much more specific.
The way I've always understood the terms are as follows.
A program in an assembly language specifies, more or less exactly,
the sequence of CPU instructions to be generated. An assembler's
job is to translate the assembly language input to machine code.
Macro assemblers make it possible for a single line of assembly
language to specify multiple CPU instructions, but the input still
specifies what machine instructions are to be generated.
My system (an x86 Linux system) has an assembler, /usr/bin/as, which
is the GNU assembler. It's used primarily as a backend to various
compilers. As far as I know, it behaves as I've described above.
(A program that reads assembly language input and performs some
optimizations before generating the final machine code is certainly
possible. I'd such a program isn't a *pure* assembler, but you
could call it an "optimizing assembler".)
A program in a higher-level, non-assembly language such as C
typically doesn't specify *any* machine instructions. Rather,
it specifies the run-time behavior of the program. A language or
dialect might have features, such as machine-code insertions or
directives, that specify things other than that, but the main point
of the program is to specify behavior. The translator for such a
language, typically called a "compiler" generates assembly or machine
code whose behavior satisfies the input program's specification.
That's the difference between an assembly language and a compiled
language: the former specifies CPU instructions, and the latter
specifies behavior. In both cases, the output consists of CPU
instructions, and those instruction implement some behavior.
The difference is in how the languages are defined.
Keith Thompson
[...]
> Adding to this, I'm not aware of a single assembly language which
> "enforces" specific machine instructions. Assembly languages may provide
> the user with a way to state what opcode they wish to use and where they
> wish to use it. Yet, nothing forces a compiler to obey that request, and
> any compiler writer is free to add some form of optimization that is able
> to generate a completely different set of opcodes. This applies to all
> languages, including any assembly language and C.
Can you provide a concrete example of an assembly language that, to a
significant degree, *doesn't* enforce specific machine instructions?
Please use something that we would both agree is reasonably called an
"assembly language"; C is not the kind of example I'm looking for.
Seebs
> Seebs wrote:
>> But "compiled by that compiler" is not an attribute of the program, it's
>> a thing you did to it. The program can be compiled with other
>> compilers.
> Exactly. What the language is and what a compiler does are two very
> different things. Therefore, it doesn't make sense to try to classify a
> particular programming language based on the features of a partcular
> compiler. After all, and as you said, the program can be compiled with
> other compilers.
Yes.
> Well, it will tie someone to a particular machine until someone invests
> his time developing a compiler which is able to abstract that and, by
> doing that, support other machines. After all, the language isn't the
> compiler and the compiler isn't the language.
This really makes no sense. No abstraction of
xor ax,ax
makes sense.
The point of assembly is that it's a description of instructions, not intent.
Please explain how you'd abstract
eieio
from a PPC macro assembler to something else...
C specifies operations on objects. Assembly specifies instructions to execute
with no reference to what those instructions *do*. It's not a question of
what you compile it to.
Angel
>> without changing a letter of the program.
>>
>> Here is, for example, the result on a Sparc64:
>> gcc -o hello hello.s
>> hello.s: Assembler messages:
>> hello.s:11: Error: Unknown opcode: `pushq'
>> hello.s:13: Error: Unknown opcode: `movq'
>> hello.s:16: Error: Illegal operands
>> hello.s:18: Error: Unknown opcode: `leave'
>>
>>
>> Now imagine how the situation for a non-trivial program would be.
>
> You've presented a compiler error caused by an attempt to compile code
> which wasn't supported by that compiler. If I try to compile Pascal code
> with gcc I will also get a bunch of error messages. Yet, that doesn't
> mean that it isn't possible to compile Pascal code on your platform.
gcc on Sparc *does* understand assembler *which is written for Sparc*,
which is exactly my whole point. An assembly language specifies machine
code, which will *only* work on the architecture it was written for.
C on the other hand, is architecture independent. It's a higher level of
abstraction, C is a third generation language while assembly is a second
generation one. There is much more to that than what macros can solve.
> If, instead, you tried to compile it with a compiler which supported that
> programming language then obviously it would work. This applies to both
> the Pascal Vs C example and your x86 Vs Sparc64 example.
Then explain please, why the C program works unmodified on both Sparc
and x86, while the assembly program does not?
Let me clue you in, there is *no* assembler in the world that can make
that program work unmodified on Sparc64.
BGB
> Rui Maciel<rui.m...@gmail.com> writes:
> [...]
>> Adding to this, I'm not aware of a single assembly language which
>> "enforces" specific machine instructions. Assembly languages may provide
>> the user with a way to state what opcode they wish to use and where they
>> wish to use it. Yet, nothing forces a compiler to obey that request, and
>> any compiler writer is free to add some form of optimization that is able
>> to generate a completely different set of opcodes. This applies to all
>> languages, including any assembly language and C.
> [...]
>
> Can you provide a concrete example of an assembly language that, to a
> significant degree, *doesn't* enforce specific machine instructions?
>
> Please use something that we would both agree is reasonably called an
> "assembly language"; C is not the kind of example I'm looking for.
>
yeah...
some people claim "C is portable assembler" but this is more generally
meant as derogatory (ephasizing its lowlevelness vs whatever is their
language of choice), rather than a literal statement.
C is still a HLL, and a C compiler is still a compiler.
for a person who has *actually* *written* compilers, the differences
between a compiler and interpreter are fairly obvious. they are,
internally, very different beasts, doing somewhat different things.
now, the question is about macro-assemblers.
thing is, some of them gloss over a few things, usually adding some
HLL-like features (such as function declarations, calls-with arguments,
expressions, if-goto, variable type-checking, ...).
but, the question does not bring simple compilers down to the level of
an assembler, but rather it means that some of these assemblers are
walking the line of turning into low-level compilers.
and, also, these sorts of assemblers are far from being the norm of what
most people do in assembler (more common I think is to use an HLL as an
HLL and an assembler as an assembler, rather than trying to use the
assembler as a compiler for some sort of arcane BASIC-like language or
similar).
foo PROC x:DWORD, y:DWORD
LOCAL z:DWORD
SET z=x+y
IF z>10 GOTO L0
...
L0:
...
foo ENDP
or such...
Michael Press
Rui Maciel <rui.m...@gmail.com> wrote:
> Michael Press wrote:
>
> > In article <4de43d29$0$16782$a729...@news.telepac.pt>,
> > Rui Maciel <rui.m...@gmail.com> wrote:
> >
> >> Michael Press wrote:
> >>
> >> > The author of a program for a macro assembler
> >> > knows exactly what machine instructions will be
> >> > produced from his program.
> >>
> >> If he uses macros, either pre-defined ones or macros which he didn't
> >> write, then he doesn't know what machine instructions will be produced
> >> by
> >> his program. If he compiles his assembly code with a compiler which
> >> performs any form of code optimization then he doesn't know what
> >> machine
> >
> > Assembly code is not compiled, it is assembled.
>
> Please define "compiled".
Have you been arguing all alone without knowing
what `to compile' means in computer programming?
It will not help if I repeat the definition of
compiler, because I will simply repeat the argument
I have been making all along. Apparently we differ
exactly on what `to compile' means, and what
`high level programming language' means.
> >> instructions will be produced by his program. And yet, the language
> >> never ceassed to be assembly.
> >>
> >> Conversely, if we have a compiler which bijectively maps C code to
> >> object code and if a programmer writes C code with that particular
> >> compiler in mind then he is able to know exactly what assembly code
> >> will be generated
> >> from his code. And yet, the language never ceassed to be C.
> >
> > We cannot specify machine instructions with C code.
>
> If you happen to compile your code with a compiler which bijectively maps
> C code to object code then how exactly would you be unable to specify
> which set of instructions would be generated?
Because the C compilers are at liberty to
choose the object code it generates from
the text of a C language program, and in
practice the same C language program will
be compiled into different assembler listings
by even the same compiler when different
command line options are chosen.
> Conversely, if you compile an assembly program with a compiler which
> performs some sort of optimization, and therefore you are unable to know,
> let alone specify which machine instructions are generated, then would
> that mean that your assembly language would from that moment on ceasse
> being an assembly language? And would that mean that the very fundamental
> nature of your programming language would depend on what compiler you
> choosed to use? Obviously, no.
Assembly code is an exact specification of a list of
machine instructions. A C language program is not.
--
Michael Press
Shao Miller
>
> Assembly code is an exact specification of a list of
> machine instructions. A C language program is not.
>
Would it be useful to pretend that the C language specifies a
"macro-assembly" translation procedure where the final, translated
elements are a sequence of values which specify behaviour, which can
then, optionally, further be translated again into machine instructions?
Or instead of behaviour, perhaps a sequence of values which specify
implementation considerations, which can then, optionally, further be
translated again into machine instructions?
Just kidding. :)
Rui Maciel
> You haven't demonstrated any paradox yet. It ceased to be an assembly
> language from the moment it's specification was written in such a form
> as to allow creation of such a compiler;
I'm not aware of any specification of an assembly language which
explicitly forbids any form of optimization and also requires that each
and every instruction must be exactly mapped to a specific opcode.
Adding to this, if your definition of a specific class of low-level
programming languages relies on this requirement then I'm not aware of a
single example of an assembly language.
Rui Maciel
Rui Maciel
How come? Do you actually believe that the definition of a programming
language depends on what compiler you happen to use to compile the code?
Rui Maciel
Rui Maciel
>> Please define "compiled".
>
> Have you been arguing all alone without knowing
> what `to compile' means in computer programming?
No. I asked you to provide your definition of "compiled" because it
clearly differs from it's true meaning. Therefore, if we intend to
exchange ideas on a subject we should at least make an effort to
understand what the other side is trying to say. Instead of asking what
was your definition of "compiling" I could've simply stated there and then
that you were wrong, but as that wouldn't help anyone I preferred to try
to know what you really meant.
> It will not help if I repeat the definition of
> compiler, because I will simply repeat the argument
> I have been making all along.
You are better off not repeating your arguments because so far they have
all been refuted.
> Apparently we differ
> exactly on what `to compile' means, and what
> `high level programming language' means.
Oddly enough, now that you demonstrate that you believe that this is the
cause of this problem, you once again avoided stating what was your
personal definition of "compiling".
>> If you happen to compile your code with a compiler which bijectively
>> maps C code to object code then how exactly would you be unable to
>> specify which set of instructions would be generated?
>
> Because the C compilers are at liberty to
> choose the object code it generates from
> the text of a C language program, and in
> practice the same C language program will
> be compiled into different assembler listings
> by even the same compiler when different
> command line options are chosen.
Can you please point out exactly where any standard definition of any
assembly language states that compilers cannot employ any form of
optimization, including removing redundant code?
>> Conversely, if you compile an assembly program with a compiler which
>> performs some sort of optimization, and therefore you are unable to
>> know, let alone specify which machine instructions are generated, then
>> would that mean that your assembly language would from that moment on
>> ceasse
>> being an assembly language? And would that mean that the very
>> fundamental nature of your programming language would depend on what
>> compiler you
>> choosed to use? Obviously, no.
>
> Assembly code is an exact specification of a list of
> machine instructions. A C language program is not.
Once again your definition of what an assembly language is is not only
basless but also detached from reality. For example, from your definition
then any assembly language which offered the most rudimentary support for
either macros or even optimization would not be a assembly language. It
would only be very, very low-level programming language.
Rui Maciel
Keith Thompson
> James Kuyper wrote:
>> You haven't demonstrated any paradox yet. It ceased to be an assembly
>> language from the moment it's specification was written in such a form
>> as to allow creation of such a compiler;
>
> I'm not aware of any specification of an assembly language which
> explicitly forbids any form of optimization and also requires that each
> and every instruction must be exactly mapped to a specific opcode.
Then show us an example of an assembly language, or of an
assembler, that *does* permit this kind of optimization, or where
the assembly language input doesn't specify the exact sequence of
CPU instructions.
> Adding to this, if your definition of a specific class of low-level
> programming languages relies on this requirement then I'm not aware of a
> single example of an assembly language.
I have /usr/bin/as on my system; it's the GNU portable assembler
configured for x86. As far as I know, it operates the way I've
described. It's entirely possible I'm mistaken on that point,
but I don't think there's any *major* flexibility in the way input
assembly is translated to output CPU instructions.
I'm almost certain that the first assembler I used (for PDP-11;
it was a long time ago) had a completely defined mapping from input
to output; at least, I was never of any other possibility.
Most assemblers these days are primarily used to handle compiler
output; the compiler generates assembly code, and the assembler
translates it to machine code. For that kind of use, I'm not sure
that optimization in the assembler would even make much sense.
The compiler knows what operations it wants to generate, and it
doesn't need the assembler second-guessing it.
Again, please show us an example of the kind of higher-level
assembler you're talking about.
Rui Maciel
> gcc on Sparc *does* understand assembler *which is written for Sparc*,
> which is exactly my whole point. An assembly language specifies machine
> code, which will *only* work on the architecture it was written for.
Indeed. And that detail means that sparc assembly is not the same
programming language as x86 assembly. Therefore, trying to compile a
program writen in language foo with a compiler for language bar is a task
clearly not destined to succeed, whether foo is pascal/x86 assembly and
bar is C/sparc assembly.
Yet, if you compile language foo with a compiler for language bar then
naturally there wouldn't be a problem.
> C on the other hand, is architecture independent. It's a higher level of
> abstraction, C is a third generation language while assembly is a second
> generation one. There is much more to that than what macros can solve.
The issue is not how different the levels of abstraction are. No one
claimed that C's level of abstraction isn't higher than any level of
abstraction employed in any assembly language. The issue being discussed
is that all programming languages are in essence macro-assembly languages
of sorts. That is, the level of abstraction, once it's there, may vary
significantly among languages but those languages end up serving the exact
same purpose: a way to specify statements which can be mapped to opcode.
>> If, instead, you tried to compile it with a compiler which supported
>> that programming language then obviously it would work. This applies
>> to both the Pascal Vs C example and your x86 Vs Sparc64 example.
>
> Then explain please, why the C program works unmodified on both Sparc
> and x86, while the assembly program does not?
Well, sparc assembly isn't the same language as x86 assembly.
> Let me clue you in, there is *no* assembler in the world that can make
> that program work unmodified on Sparc64.
That may be true, as I don't believe there is a high demand for a tool
that performs that task. If there was then it is quite obvious that it
would be far from impossible to write it.
Rui Maciel
Rui Maciel
>> Well, it will tie someone to a particular machine until someone invests
>> his time developing a compiler which is able to abstract that and, by
>> doing that, support other machines. After all, the language isn't the
>> compiler and the compiler isn't the language.
>
> This really makes no sense. No abstraction of
> xor ax,ax
> makes sense.
Tell me this: is it impossible to perform that specific operation, either
through a single instruction or through a set of instructions, in two
different architectures? If it is possible then it is also possible to
express that operation through an assembly language which supports both
architectures.
> The point of assembly is that it's a description of instructions, not
> intent.
>
> Please explain how you'd abstract
> eieio
> from a PPC macro assembler to something else...
If the processor architecture doesn't support out of order execution then
it can be omitted. If the target architecture supports it but doesn't
provide a way to enforce in-order execution then there could be a problem,
but I'm not aware of such a case.
Rui Maciel
Billy Mays
> Then show us an example of an assembly language, or of an
> the assembly language input doesn't specify the exact sequence of
> CPU instructions.
Just to play Devil's Advocate, I am frequently using an assembly
language called PTX which is used for nVidia Graphics cards. PTX
functions as an intermediary assembly language that at runtime gets
compiled differently depending on what GPU you have.
--
Bill
Keith Thompson
> Michael Press wrote:
>
>>> Please define "compiled".
>>
>> Have you been arguing all alone without knowing
>> what `to compile' means in computer programming?
>
> No. I asked you to provide your definition of "compiled" because it
> clearly differs from it's true meaning. Therefore, if we intend to
> exchange ideas on a subject we should at least make an effort to
> understand what the other side is trying to say. Instead of asking what
> was your definition of "compiling" I could've simply stated there and then
> that you were wrong, but as that wouldn't help anyone I preferred to try
> to know what you really meant.
I don't recall that you've provided *your* definition of
"compiled". Your assertion that you're using the "true meaning"
is not particularly helpful.
What do you mean by "compiled"?
[...]
> Can you please point out exactly where any standard definition of any
> assembly language states that compilers cannot employ any form of
> optimization, including removing redundant code?
I'm not personally aware of any standard definition of any assembly
language. I have used several, and there has generally been some
documentation that describes them, but nothing that I'd call a standard.
And your use of the word "compilers" to refer to translators for
"assembly language" means that you're using one or both terms in a sense
that's very different from the way I use them. It also seems to differ
from the way everyone else in this discussion uses them.
It's possible that you're the only person here who's using the
terms correctly. If so, please help us out by sharing your correct
definitions with the rest of us.
[...]
> Once again your definition of what an assembly language is is not only
> basless but also detached from reality. For example, from your definition
> then any assembly language which offered the most rudimentary support for
> either macros or even optimization would not be a assembly language. It
> would only be very, very low-level programming language.
Assembly languages certainly can (and usually do) support macros. It
just means that I need to know the definitions of any macros used to
know what machine code will be generated.
As for optimization, I've never heard of an optimizing assembler. As
soon as you provide an example, I'll have heard of one. If it takes
assembly code as input and generates CPU instructions that don't
necessasrly match what was specified by the input, but that have the
same behavior, then I wouldn't say it's no longer an assembler, but it's
no longer a *pure* assembler.
And yes, as far as I know there are plenty of "pure" assemblers in
common use.
Proposed definitions:
A "pure assembler" is a translator whose input consists of assembly
language which may include:
Textual representations of instructions for a specified CPU and
their operands (example: "movl %esp, %ebp").
Various directives that affect the generated code (example:
".section rodata").
Macro definitions and invocations that expand to the above (I don't
have an example handy).
and whose output consists of CPU instructions and is entirely determined
by the input.
A "pure HLL compiler" is a translator whose input consists of code
in some high level language. The input describes the intended
behavior of the program (not necessarily unambiguously) without
reference to any CPU instructions. The output is a machine-code
program that implements the specified behavior. The translator is
free to choose varying instruction sequences. (Often the compiler
generates textual assembly code which is then translated by an
assembler, which may or may not be a "pure assembler").
There's a fairly wide gap between these two kinds of translator, wide
enough that a given translator cannot be both a "pure assembler" and a
"pure compiler".
There are systems that fall somewhere into this wide gap. Prior to this
discussion, the only such systems I was aware of were HLL compilers that
support some kind of inline asssembly. There could, of course, be a
plethora of other intermediate systems that I'm not aware of. If a
translator's input consists mostly of textual representations of specific
CPU instructions, or of macro invocations that exanpd to such
representations, I'd call that translator an assembler even if it isn't
a "pure assembler".
You seem to be claiming that few, if any, modern macro assemblers are
"pure" in the sense I've described. I am frankly skeptical of this
claim, and I ask you to support it with concrete examples.
Please stop assuming that you're right and everyone else is wrong, and
that we'll all realize it as soon as we gain a correct understanding of
reality. Or at least *tell us* what you're talking about.
Angel
> Angel wrote:
>
>> gcc on Sparc *does* understand assembler *which is written for Sparc*,
>> which is exactly my whole point. An assembly language specifies machine
>> code, which will *only* work on the architecture it was written for.
>
> Indeed. And that detail means that sparc assembly is not the same
> programming language as x86 assembly. Therefore, trying to compile a
> program writen in language foo with a compiler for language bar is a task
> clearly not destined to succeed, whether foo is pascal/x86 assembly and
> bar is C/sparc assembly.
Except for the little fact there is no such thing as "Pascal assembly"
or "C assembly", and a correctly written Pascal or C program *does* work
as specified regardless of whether the underlying architecture is Intel
or Sparc. (Unless of course it does something that is impossible or
makes no sense on the target architecture.)
Also, it's not even the hardware so much. An assembly program written
for DOS will most likely not work on Linux or OS/2.
> Yet, if you compile language foo with a compiler for language bar then
> naturally there wouldn't be a problem.
And yet it is in most cases fairly trivial to make a C program written
for one compiler work under another, as long as both compilers support
the standard.
>> C on the other hand, is architecture independent. It's a higher level of
>> abstraction, C is a third generation language while assembly is a second
>> generation one. There is much more to that than what macros can solve.
>
> The issue is not how different the levels of abstraction are. No one
> claimed that C's level of abstraction isn't higher than any level of
> abstraction employed in any assembly language. The issue being discussed
> is that all programming languages are in essence macro-assembly languages
> of sorts. That is, the level of abstraction, once it's there, may vary
> significantly among languages but those languages end up serving the exact
> same purpose: a way to specify statements which can be mapped to opcode.
Then go ahead and map the statement a = b; to an opcode. Go on, we're
waiting.
Saying "all languages are in essence macro-assembly languages" is a very
crude and overly broad simplification that shows you actually know very
little about how a compiler works and what sorts of problems it has to
deal with.
The only thing that is true is that both a compiler and an assembler
eventually output something that can be understand by the machine, but
the processes by which they get there are quite different.
>> Let me clue you in, there is *no* assembler in the world that can make
>> that program work unmodified on Sparc64.
>
> That may be true, as I don't believe there is a high demand for a tool
> that performs that task. If there was then it is quite obvious that it
> would be far from impossible to write it.
No it is impossible to write such assembler, because as you have stated
above yourself it is x86 assembler, specifing a machine code that the
Sparc simply does not understand.
You could perhaps write a program that translates it to Sparc assembler
that functions in a similar way, although I'm afraid you'll find that a lot
harder than you seem to think. And regardless, what you have written
then is not an assembler.
A second generation language maps instructions directly to opcodes, a
third generation language does not.
Seebs
>>> Well, it will tie someone to a particular machine until someone invests
>>> his time developing a compiler which is able to abstract that and, by
>>> doing that, support other machines. After all, the language isn't the
>>> compiler and the compiler isn't the language.
>> This really makes no sense. No abstraction of
>> xor ax,ax
>> makes sense.
> Tell me this: is it impossible to perform that specific operation, either
> through a single instruction or through a set of instructions, in two
> different architectures?
Not in general, no.
Look at it this way: How would you do that on one of the Cell's SPE
units? Or, heck. PowerPC. What exactly is the equivalent of
xor ax,ax
on PowerPC?
Answer, there isn't one, *because there is no such thing as ax*. The PowerPC
chip does not have the same map of registers.
Similarly, let's say we start with some 68k assembly.
moveq #0,d0
moveq #0,d1
moveq #0,d2
moveq #0,d3
moveq #0,d4
moveq #0,d5
moveq #0,d6
moveq #0,d7
You can't translate this to x86, because x86 doesn't HAVE eight general
purpose data registers like that. (And if my memory's wrong, and it does,
no problem; just pop over to SPARC or something where there's even MORE
general purpose registers.)
> If it is possible then it is also possible to
> express that operation through an assembly language which supports both
> architectures.
But it's not possible, because the entire point is that the architectures
DON'T have corresponding elements.
>> Please explain how you'd abstract
>> eieio
>> from a PPC macro assembler to something else...
> If the processor architecture doesn't support out of order execution then
> it can be omitted. If the target architecture supports it but doesn't
> provide a way to enforce in-order execution then there could be a problem,
> but I'm not aware of such a case.
There's a lot more to it than that. The semantics are not as simple as
a quick summary might make it sound.
The point of using assembly is that it lets you do things which simply
*don't* map to other chips. Say you're on an x86, and you're in segmented
mode. There's *nothing* you can do on a 68k that is even analagous to the
trickery that goes on when you take advantage of overlapping segments on
x86.
So, really, that's where this all breaks down; in reality, assembly code
is full of things which simply do not translate. That's why people use
it; because there's no way to express these things except in terms of a
given CPU. What bits might be set outside of the directly affected registers
by an operation? Different bits on different CPUs for different operations,
and the registers they'd be set in aren't necessarily translateable.
And this is why you can't meaningfully talk about an assembler being
portable in the way that C is. Fundamentally, C is specifying *semantics*,
which are an abstraction that need not correspond to specific processor
events. There are operations in C that generate no code on one machine
and lots of code on another, because the "function" described is irrelevant
in one system and complicated in another. Assembly, by contrast, is
specifying *instructions*. They don't necessarily have semantic content
that is comprehensible in any way separate from the details of that specific
chip. If you execute an instruction to "clear condition code register", that
doesn't necessarily translate to a machine which has more than one such
register, using them for different things. You can't talk about the
semantics of the code and translate at that level, because the code hasn't
*got* abstract semantics.
The closest you could come would be to write an entire processor simulator
and then just assemble the code. This clearly leaves us with a gigantic
difference between C and a "macro assembler".
Shao Miller
> The issue is not how different the levels of abstraction are. No one
> claimed that C's level of abstraction isn't higher than any level of
> abstraction employed in any assembly language. The issue being discussed
> is that all programming languages are in essence macro-assembly languages
> of sorts. That is, the level of abstraction, once it's there, may vary
> significantly among languages but those languages end up serving the exact
> same purpose: a way to specify statements which can be mapped to opcode.
>
On 6/2/2011 1:06 AM, Shao Miller wrote:
> Would it be useful to pretend that the C language specifies a
> "macro-assembly" translation procedure where the final, translated
> elements are a sequence of values which specify behaviour, which can
> then, optionally, further be translated again into machine instructions?
>
> Or instead of behaviour, perhaps a sequence of values which specify
> implementation considerations, which can then, optionally, further be
> translated again into machine instructions?
>
> Just kidding. :)
Or not. :)
To be honest, I'd really enjoy a sample implementation of a "C
byte-code" whose scope is as close to a Standard C as possible (and no,
not a source file, heh). Even better would be if the byte-code could be
translated "back up" and resemble the original source, perhaps minus
comments and whitespace detail.
James Kuyper
No, I just see no connection between your re-iterated assertion that
we're confusing the compiler with the langauge, and reality.
--
James Kuyper
James Kuyper
> James Kuyper wrote:
>
>> You haven't demonstrated any paradox yet. It ceased to be an assembly
>> language from the moment it's specification was written in such a form
>> as to allow creation of such a compiler;
>
> I'm not aware of any specification of an assembly language which
> explicitly forbids any form of optimization and also requires that each
> and every instruction must be exactly mapped to a specific opcode.
All three of the assembly languages I was familiar a couple of decades
ago had precisely those characteristics, but you'll probably dismiss
them as obsolete. It's not so much that optimization was prohibited, as
that it was considered to be the responsibility of the programmer, not
the assembler. If I told the assembler to generate a particular sequence
of instructions, and it produced a different sequence, it was
malfunctioning, and that's all there was to that. There was no mechanism
for saying "I want the fastest sequence of instructions that will
implement this particular behavior"; there was no syntax for describing
the desired behavior, on a syntax for describing the desired machine
instructions. I'm curious what syntax your more modern ones use for that
purpose?
In particular, how do you turn optimization off? If I were to specify a
particular sequence of instructions because I've carefully determined
that it results in the correct timing for dealing with external
hardware, I'm going to be thoroughly upset if the assembler optimizes
the code to execute faster, ruining the timing.
> Adding to this, if your definition of a specific class of low-level
> programming languages relies on this requirement then I'm not aware of a
> single example of an assembly language.
Well, I'm familiar with three.
--
James Kuyper
io_x
"Rui Maciel" <rui.m...@gmail.com> ha scritto nel messaggio
news:4de22bd1$0$16159$a729...@news.telepac.pt...
> Keith Thompson wrote:
>
>> I would say that you're ignoring the meaning of "macro-assembly".
>>
>> A program in a macro-assembly language specifies (perhaps indirectly in
>> some cases) the CPU instructions to be generated. A program in a high
>> level language, including C, specifies behavior.
>
> ...which also specifies the CPU instructions that are generated from the
> source code, although it may not do that in a bijective way and it may
> vary with the degree of abstraction.
assembly language is a set of macro or instruction each one in the
text is written in the way there exist
1-1 map from set of symbols in it to cpu instructions
example
"a==b#.3"
"a==b" <-> "cmp eax, ebx" <-> cpu bytes
"#.3" <-> "je .3" <-> cpu bytes
this is an assembly instruction
even it is illogical because could be too
"a!=b#.3"
"a!=b" <-> "cmp eax, ebx" <-> cpu bytes
"#.3" <-> "jne .3" <-> cpu bytes
and "#.e" has 2 different meaning
instructions <-> "mov eax, ebx\n mov ecx, edi"
and instructions **is not** one assembly instruction
the key point is in assembly when you see the text you
see the cpu instruction too
it is possible to write assembly language routines
much complex of the ones is possible to write in C
or in C++ without loose the readability
where "readability" means understand what happen
i don't know if one language without UBs
can be said assembly too
> To put it differently, once you
> recognize and accept the "indirectly" bit, the distinction between the
> compiler of a macro language and the compiler of a high-level programming
> language amounts to nit-picking regarding how much optimization it may or
> may not employ, which is a discussion of how much grey is supposed to be
> grey.
>
>
> Rui Maciel
BartC
news:4de64db9$0$16783$a729...@news.telepac.pt...
> Keith Thompson wrote:
>
>> Rui Maciel <rui.m...@gmail.com> writes:
>>> Stefan Ram wrote:
>>>> ISO/IEC 9899:1999 (E) does nowhere specify that this code
>>>> has to be generated. Any other code that behaves /as-if/
>>>> is as well, like »fputs( "hello, world", stdout )«.
>>>>
>>>> A macro assembler allows you to /enforce/ a specific
>>>> machine instruction.
>>>
>>> In this case it's irrelevant what the C standard specifies and doesn't
>>> specify.
>>
>> It's entirely relevant to the point most of us are trying to discuss.
>
> The issue being discussed is that all high level programming languages are
> macro-assembly languages of sorts.
OK. So forgetting all concrete implementations of languages using
conventional compilers, interpreters and assemblers, you're suggesting that
*any* high level language, even some future language that does not yet
exist, could be defined in terms of some other, currently existing language
called a 'macro-assembler'.
Let's assume this 'macro-assembler' is powerful enough that it will
recognise *any* desired syntax of any language. And powerful enough to be
able to implement any desired semantics (leaving aside the problem of
exactly how you specify those semantics).
So, in that case you're probably right; any language *can* probably be
specified in terms of such a beast.
But so what? It seems clear that such a language does not yet exist; some
effort is necessary to map *any* language to *this* language, so is not any
different to writing a conventional implementation (otherwise, let's just
use English as our high level language, if all it needs is to write a few
macros).
And since it doesn't yet exist (unless you want to come up with the examples
that we're all waiting for), then no, not *all* high level languages are
variations of just one macro-assembly language. (It would have to be 'one'
language, since if each HLL was implemented using it's own dedicated
macro-assembly language, then your assertion is meaningless.)
--
Bartc
Keith Thompson
> In article <is9gb8$9td$1...@dont-email.me>, James Kuyper <james...@verizon.net>
>> All three of the assembly languages I was familiar a couple of decades
>> ago had precisely those characteristics, but you'll probably dismiss
>> them as obsolete. It's not so much that optimization was prohibited, as
>
> set for machine M while running on machine M. They dynamically detect basic
> blocks, traces, etc, and then cache increasingly optimised versions of the code.
I thought we were talking about assemblers, not interpreters.
Michael Press
Billy Mays <no...@nohow.com> wrote:
"Parallel Thread Execution is a pseudo-assembly
language used in nVidia's CUDA programming environment.
The 'nvcc' compiler translates code written in CUDA, a
C-like language, into PTX, and the graphics driver
contains a compiler which translates the PTX into
something which can be run on the processing cores."
--
Michael Press
Michael Press
Shao Miller <sha0....@gmail.com> wrote:
Glad you added that. Reading your conjectures made
my brain glaze over just as if I were reading RM.
--
Michael Press
Michael Press
Rui Maciel <rui.m...@gmail.com> wrote:
> Michael Press wrote:
>
>
> >> Please define "compiled".
> >
> > Have you been arguing all alone without knowing
> > what `to compile' means in computer programming?
>
> No. I asked you to provide your definition of "compiled" because it
> clearly differs from it's true meaning. Therefore, if we intend to
> exchange ideas on a subject we should at least make an effort to
> understand what the other side is trying to say. Instead of asking what
> was your definition of "compiling" I could've simply stated there and then
> that you were wrong, but as that wouldn't help anyone I preferred to try
> to know what you really meant.
As I said, the definitions I adhere to are
embedded in the arguments I already wrote out.
> > It will not help if I repeat the definition of
> > compiler, because I will simply repeat the argument
> > I have been making all along.
>
> You are better off not repeating your arguments because so far they have
> all been refuted.
Not so as I noticed.
> > Apparently we differ
> > exactly on what `to compile' means, and what
> > `high level programming language' means.
>
> Oddly enough, now that you demonstrate that you believe that this is the
> cause of this problem, you once again avoided stating what was your
> personal definition of "compiling".
I do not have a personal definition of "compiling"
because the constellation of properties I assign to the
verb "to compile" is shared by many people. That is the
definition of "definition." You have what you call a
"personal definition", and so far you are the only one
using it. Therefore your notion is not yet a definition.
> >> If you happen to compile your code with a compiler which bijectively
> >> maps C code to object code then how exactly would you be unable to
> >> specify which set of instructions would be generated?
> >
> > Because the C compilers are at liberty to
> > choose the object code it generates from
> > the text of a C language program, and in
> > practice the same C language program will
> > be compiled into different assembler listings
> > by even the same compiler when different
> > command line options are chosen.
>
> Can you please point out exactly where any standard definition of any
> assembly language states that compilers cannot employ any form of
> optimization, including removing redundant code?
Can you point out any definition of assembly language
that specifies any property of compilers?
> >> Conversely, if you compile an assembly program with a compiler which
> >> performs some sort of optimization, and therefore you are unable to
> >> know, let alone specify which machine instructions are generated, then
> >> would that mean that your assembly language would from that moment on
> >> ceasse
> >> being an assembly language? And would that mean that the very
> >> fundamental nature of your programming language would depend on what
> >> compiler you
> >> choosed to use? Obviously, no.
> >
> > Assembly code is an exact specification of a list of
> > machine instructions. A C language program is not.
>
> Once again your definition of what an assembly language is is not only
> basless but also detached from reality. For example, from your definition
> then any assembly language which offered the most rudimentary support for
> either macros or even optimization would not be a assembly language.
Not so. Assembly macros specify exactly a list of machine instructions.
Your argument is refuted.
> It
> would only be very, very low-level programming language.
Assembly language, even with assembly macros,
is a low-level programming language. "Low" here
is not a value judgement. Deep and subtle ideas
can be manifested in assembly language.
--
Michael Press
Rui Maciel
> I thought we were talking about assemblers, not interpreters.
Interpreters demonstrate that it is possible to map any set of
instructions in language A to a set of instructions in language B, which
in this case are different instruction sets. As assembly languages are
abstractions of any given instruction set then the same conclusion also
applies to any mapping between assembly languages.
Rui Maciel
Angel
Interpreters are case-specific, written for a particular language and
often for a specific architecture as well. Their existence does not
prove that what you say is true in general for all instruction sets.
https://secure.wikimedia.org/wikipedia/en/wiki/Hasty_generalization
Anyway, your claim is false, I am 100% certain I can write a set of
instructions for sparc64 that cannot be mapped in any meaningful way to
x86.
Keith Thompson
If the requirement is that the mapping maintains the visible behavior
of the program, then that seems like an unremarkable claim --
and not one that supports your earlier assertions.
Something that might help support your earlier assertions is
a concrete example of a "macro assembler" that doesn't strictly
define the generated machine code for a given input. I've asked
for such an example several times. Does one really exist?
Keith Thompson
> On 2011-06-04, Rui Maciel <rui.m...@gmail.com> wrote:
>> Keith Thompson wrote:
>>> I thought we were talking about assemblers, not interpreters.
>>
>> Interpreters demonstrate that it is possible to map any set of
>> instructions in language A to a set of instructions in language B, which
>> in this case are different instruction sets. As assembly languages are
>> abstractions of any given instruction set then the same conclusion also
>> applies to any mapping between assembly languages.
>
> Interpreters are case-specific, written for a particular language and
> often for a specific architecture as well. Their existence does not
> prove that what you say is true in general for all instruction sets.
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Hasty_generalization
>
> Anyway, your claim is false, I am 100% certain I can write a set of
> instructions for sparc64 that cannot be mapped in any meaningful way to
> x86.
Oh? What if I write a sparc64 emulator in x86 assembly language?
Kleuskes & Moos
<snip>
> https://secure.wikimedia.org/wikipedia/en/wiki/Hasty_generalization
>
> Anyway, your claim is false, I am 100% certain I can write a set of
> instructions for sparc64 that cannot be mapped in any meaningful way to
> x86.
Doesn't Turing object to that?
http://en.wikipedia.org/wiki/Universal_Turing_machine
http://en.wikipedia.org/wiki/Turing_completeness
Seebs
> Oh? What if I write a sparc64 emulator in x86 assembly language?
Hmm.
That leads to an interesting design for the assembler. Assume an emulator
which works on string arguments which have the form of assembly mnemonics.
You can then translate every input assembly menmonic string to
.literal L2281 "sparcopcode args"
push L2281
call emulate
or whatever the equivalent is. Obviously, this will in fact have the expected
behavior, assuming you have some magic in place to handle assembly features
such as labels... This could get very interesting.
You'd have to do one pass through assigning addresses to all the labels and
such, and things like that, but I think you could, in fact, do it.
I think, though, that looking at such a thing establishes that the claim
that you can translate from one to the other through something called a
"macro assembler" is either totally meaningless or false. At that point,
we are out of meaningful distinctions that allow us to say that something
is, or is not, a macro assembler. We might as well describe the process
by which grass becomes runny lumps of mostly black and white goo as "a
macro assembler" rather than "a goose".