Re: i disagree

On Jan 26, 11:06 pm, "Charles A. Crayne" <ccra...@xxxxxxxxxx> wrote:
On 26 Jan 2007 16:21:58 -0800

"r...@xxxxxxxxxx" <r...@xxxxxxxxxx> wrote:

:I always took you for one who was intelligent enough to know the
:difference between a language and an implementation of that language.

If you would stop setting up and knocking down straw man arguments long
enough to read what I actually wrote, you might not only increase your
appreciation for my intelligence,

Fundamentally, you're not improving my perception of you.


1. I do not claim, nor have I ever claimed, a 1:1 relationship between a
the input file to an assembler and the machine code which is generated
from that file. Anyone who does so claim is, at best, setting up a straw
man which can easily be refuted by noting that even the "purest" of
assemblers accepts a variety of input lines which produce no machine code
at all.

But you *have* claimed that a macro, which generates *three* assembly
language statements, yielding three machine instructions, does not
violate this. If you think that I'm restating your claim in a weaker
form so I can refute it, please elaborate.



2. I do not claim, nor have I ever claimed, that an assembly language
statement must be contained in exactly one physical input line.

I don't believe anyone around here has made any requirement about one
physical input line. Certainly I have not. This may be true that
you've never made such a claim, but it is completely irrelevant in the
current debate as no one is making such claims.


Anyone who
does so claim is, at best, setting up a straw man which can easily be
refuted by noting that even in the days of punch cards, assembly language
statements could be continued on the next card by placing an x in card
column 72.

To my knowledge, no one has done so. What is the point of this claim?



3. I do not claim, nor have I ever claimed, that there was once a 1:1
relationship in "pure" assemblers, which has since been made obsolete by
the introduction of macro assemblers.

No, but others around here certainly have.

Anyone who does so claim is, at
best, setting up a straw man which can easily be refuted by noting that
this event would have had to have taken place before the widespread use of
macro assemblers, which was at least as far back as 1956 (e.g. MAP on the
IBM 7090/7094), a fact to which I, myself, can testify.

So you are claiming that macro assemblers have made any such claim of
1:1 obsolete, if such a claim could have been substantiated at any
time, right? Welcome to the club. That is *exactly* the claim I've
been making for quite some time now. If you are not claiming this,
then feel free to refute the impression that you are giving with
paragraph 3.



4. I do not claim, nor have I ever claimed that a 1:1 relationship exists
between the input to a macro and the output generated by that macro.
Anyone who does so claim is, at best, setting up a straw man which can
easily be refuted by looking at the macro expansion. In the specific case
of hla, this means comparing the *.hla file to the corresponding *.asm
file.

Do you know what the term "straw man argument" means here? It really
sounds like you're abusing the term in this paragraph.



5. I do not claim, nor have I ever claimed that the output of a macro is
machine language instructions.

Irrelevant to the discussion. We *are* discussing machine instructions
in this thread. Indeed, based on the couple of times you've mentioned
directives and pseudo-opcodes, I would hope that it became clear to
you that this thread is ignoring such things, just as we're basically
ignoring the fact that instruction encoding in Intel Syntax assembly
language fails 1:1 even for the "purest" of assemblers.


Anyone who does so claim is, at best,
setting up a straw man which can easily be refuted by looking at the input
to the code generation pass(es) of the assembler. For example, although
the bottle.hla program contains a number of hla macros, none of these
macros are passed through to the bottle.asm file

Like the previous point, this statement demonstrates that you don't
understand what "straw man argument" means.

Also, as I interpret this (ambiguous) English statement, what you're
saying is that "anyone who claims that you claim the output of a macro
expansion is machine instructions" is setting up a straw man argument,
which (the argument) can be easily refuted by compiling bottle.hla.
Now had *you made the claim* the claim could so be refuted by
compiling bottle.hla, but it would not refute their argument (indeed,
it would bolster their argument). If this latter is what you mean,
then they would hardly be setting up a "straw man argument", they
would be refuting your claim. Now if they are setting up a straw man
argument and, as such, somehow claiming that you made the claim that
"the output of a macro expansion is machine instructions", then
compiling bottle.hla would prove absolutely nothing.


6. What I do claim is that the 1:1 terminology, as used by experienced
assembly language programmers, applies only to those assembly language
statements which are directly converted to machine language by the code
generation portion of an assembler, and does not, and has never, referred
to the statements which are handled by text manipulation portion(s).

Alas, like Rene, you don't seem to understand the difference between a
language and an implementation of that language. This is profoundly
demonstrated by this last point. If you were expecting to demonstrate
some your intelligence and impress me here, I'm afraid you've failed.
Cheers,
Randy Hyde


.

Relevant Pages

  • Re: i disagree
    ... One can set up a straw man in the following ways: ... :language and an implementation of that language. ... the "language" that an assembler ... macro processor built into the system. ...
    (alt.lang.asm)
  • Re: i disagree
    ... :difference between a language and an implementation of that language. ... If you would stop setting up and knocking down straw man arguments long ... assemblers accepts a variety of input lines which produce no machine code ... the introduction of macro assemblers. ...
    (alt.lang.asm)
  • Re: i disagree
    ... :difference between a language and an implementation of that language. ... If you would stop setting up and knocking down straw man arguments long ... assemblers accepts a variety of input lines which produce no machine code ... the introduction of macro assemblers. ...
    (alt.lang.asm)
  • Re: A (mild-mannered) defense of RosAsm
    ... there actually *are* some features in RosAsm ... > All these debates over RosAsm's macro language remind me of Jerry ... There are actually *weaker* assemblers out there than I fully support. ...
    (alt.lang.asm)
  • Re: C# programmer wants to learn assembly?? plz help
    ... times for experts in that language, ... The cost of learning asm, is to use from 20 to 40 diffrent instructions. ... 1000s of other libraries that makes C what it is. ... other poor exuses for assemblers thats out there. ...
    (alt.lang.asm)