Re: HLA

Rod Pemberton wrote:
"santosh" wrote
Rod Pemberton wrote:
?. I was referring to adding HLA into another C compiler using HLA as the
inline assembler for that compiler.

Why? HLA is in some respects higher level than C. Inline assembly is a
different beast from a standalone assembler and IMHO, HLA is most
unsuitable for this purpose.


You haven't been paying attention. HLA's syntax is close to C.

Where did I say otherwise? I said that, in my _opinion_, HLA, being a
very high level assembler, is not suitable for adding as an inline asm
to C.

All widely used C and C++ compilers already have an inline asm facility
and, in most cases, also a standalone assembler in the overall package.
Though it's certainly possible, why would anyone use HLA for this
purpose. It's not designed for such use and, IMHO, ill suited for it.


time will change you...

Whatever do you mean?

For example GCC could
possibly support inline asm even without GAS, as long as it can
translate it to the backend assembler's syntax.

True. Now think about an inline asm syntax that is very close to C's
grammar. It could be added to almost any C compiler without problems...

We already _have_ inline asm for all the major compilers. Adding HLA as
an inline asm syntax into a C/C++ compiler will be a very complex and
major undertaking, which, except you, no one seems to be asking for.


No. It's not "a very complex and major undertaking", but your posts
indicate you have no experience here...

Yes. I don't have experience in compiler implementation. But it's
probably a good guess that hacking HLA into a compiler like GCC won't
be easy by any means.

But if it's as easy as you seem to indicate why not "have at it", as
Randy likes to say. HLA in Public Domain, so you're free to play around
with it. Randy probably has better things to do than turning it into an
inline asm language.

.... snip ...

As has been pointed out to you on numerous ocassions in comp.lang.c, if
you use compiler specific extensions to a standardised langauge, (say
C), then you're no longer programming in the standard form of the
langauge.


Given,
Sn> We already _have_ inline asm for all the major compilers.

So, using only your statements, no major compilers allows one to "program in
the standard form of the language"...

That's what you're deriving, not what I'm saying. Note well:

Compilers, (atleast conforming ones), certainly allow one to program in
the standard form of the langauge, as long as one sticks to it. The
moment you start using compiler specific extensions, (like inline asm),
you've left the standard form of the langauge.

Does the above paragraph imply that [sic] "no major compilers allows
one to program in the standard form of the language"?

I don't think that is what you meant to say,

You got it.

but you said it. I think you have a basic understanding that the two are different...

Correct. But just like a compiler, you seem to be interpreting my words
literally.

"changing the language" versus "programming in the standard form of the
language". The two are _very_ different.

Correct. The former is an implementation side issue, the latter is a
client side one.

One can program in the standard
form of the language in an environment where the language has been extended.
This is because the language wasn't changed. It was only extended.

Sure, but what has all this got to do with the debate over whether HLA
is a suitable assembly syntax for inlining into a HLL compiler?

Sure, the semantics of the _vast_ majority of the langauge may still be
identical to the standard, but even so, the code cannot be a standard
conforming one.

Given,
Sn> We already _have_ inline asm for all the major compilers.

Basically, you state the code "for all the major compilers" "cannot be a
standard conforming one." So, what good does the standard serve if no one
complies with it 100%? (That was rhetorical...)

Your whole post appears to be rhetorical.

There is no such thing as "code for all major compiler". You're
combining my words with yours and taking things out of context.

Each body of code can either conform to the langauge standard, or by
taking advantage of compiler/platform specific stuff, not be standard
compliant.

This is, (hopefully), clear to everyone. From this, you're jumping to
the assertion that "code for all major compilers cannot be a standard
conforming one". Where did you pull that one out of!?

True, but the point was about one specific case: HLA. HLA is _almost_
compliant with the C grammar. HLA could be much more useful if it were
fully compliant.

In which case it would become a non-standard variant of the C langauge,
queerly restricted to one architecture. Your vision is so wierd, I
doubt barely anyone would want it to come to pass.


Given,
Sn> We already _have_ inline asm for all the major compilers.

So, now you're claiming that "all the major compilers" are "so wierd, I
doubt barely anyone would want it to come to pass" despite the fact it
already has for all of them. [...]

No wonder you've been widely killfiled over in comp.lang.c. Like a
broken compiler, you're taking my words out of context, combining them
ones of your own, and then complaining that the whole hodgepodge
doesn't make sense!

Note well:

I'm claiming that integrating _HLA_ as an inline asm into a HLL
compiler is weird enough that few will want it. Not that any and all
inline asm syntaxes are weird, _only HLA_.

I hope you get it now. If you're still confused, feel free to followup.

BTW, if there had been a high enough demand for integrating HLA into a
HLL, Randy would probably have done so. By his own words, HLA was
designed, first and foremost, as a tool to teach assembly to students.

In _my_ opinion, making it into an inline asm would have not helped the
students at their objective. Indeed it would have slowed down their
pace of learning. YMMV.

----

"All the major compilers," at some point in their life cycle, went through
the exact same process you call a "wierd vision." Why do you fault me for
wanting and trying to do the same?

Where did I _fault_ you? I gave _my view_ on your idea. Am I supposed
to unquestioningly agree with all you post? Why are you so intolerant
to difference of opinion?

Do you believe Thomas Edison's idea of
a non-burning glowing filament was a "wierd vision" too?

Nope. You're again making the mistake of extrapolating from my
_specific_ statement, (that inlining HLA into a HLL is weird), and
generalising them far beyond their intended context, with the sole
intent of trolling.

----

You previously stated, to paraphrase, that you oppose having a stagnant and
non-innovative field of programming. So, why do you attempt to stifle my
innovations, even if they are limited?

You seem to be mistaking me for the FBI... Yet again: I gave _my
opinion_ on your idea. You're absolutely free to disagree and
"innovate" by creating an inline version of HLA. I'm sure Randy will be
happy to give any support needed.

Nobody has "stifled" anyone here.

I have decades of programming experience.

I don't doubt it.

My IQ is very high (proven).

I'm happy for you. Maybe you should consider RosAsm instead of HLA for
your inlining efforts. Betov specifically targets his language at those
with "IQ above 80"
:)

Yet, you try to tell me my idea is stupid...

No, not stupid, (another word you've "made up" here). Just that it's
weird and probably unnecessary. weird != stupid.

I know better.

Good for you then. We'll all be eagerly awaiting the release of "inline
HLA" :)

Have you considered that something you believe
to be a waste of time, isn't?

Sure. That's why I have repeated ad nauseum that it was my _opinion_.
Not a statement of fact. If you're sensitive to difference of opinion,
you probably should not post to a public forum like Usenet.

Have you considered that it is you who isn't at my level?

I have, and I'm not sure I want to come down to your level of
argumentation.

[snipped excursion into "locane powder", "William Goldman", "Yahoo" and
"Australian poison"]

If you thought it was or still think that it is just a literary device, then
the "experts" on comp.lang.c are just right for you. If you prefer a real
expert in C, you'd be wise to study what Douglas A. Gwyn says, not those
other clowns.

Thanks, I've been reading Douglas's posts just as much as the ones from
"those other clowns".
In future, you'd do well to take _your_ spat with comp.lang.c regulars,
over to the appropriate group.

.

Relevant Pages

  • Re: Function Pointers and Inlining
    ... >>to inline those calls which it is able to inline. ... The Standard does not mandate either behaviour. ... into the code instead of a call to that function (known as "inlining") is ... is where the behaviour of a compliant compiler lies. ...
    (comp.lang.cpp)
  • Re: Beginners and All That Are New To Assembly Language - Read This
    ... the compiler adds. ... So there's no logical way to describe HLA as inline ... assembly because there's no embedding going on. ...
    (alt.lang.asm)
  • Re: What micros do you actually hate to work with?
    ... the least extra intrinsics. ... It is unlikely intrinsics will soon become part of the official C standard - ... in a highly optimizing compiler (like inline assembler...). ...
    (comp.arch.embedded)
  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... Program name in quotes (allowed in '02 Standard) ... > If J can be made an independent item which the compiler can put wherever it ... > has to be associated with a hardware device in SPECIAL-NAMES. ... > that ALTER *always* modifies the address parameter of the hardware branch ...
    (comp.lang.cobol)