Portable "asm" <-- portable? since when?

[Dave Burton]

In article <697 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
|In article <7401 at brl-smoke.ARPA>, gwyn at brl-smoke.ARPA (Doug Gwyn ) writes:
|> In article <2738 at mmintl.UUCP> franka at mmintl.UUCP (Frank Adams) writes:
|> >Clearly, assembler statements should have been defined as:
|> >#asm <statement>
|> >instead of
|> >asm("statement");
|> 
|> A properly-designed system programming language should not have such
|> a feature at all.  (It is not guaranteed in C, either.)  

What's all this about #asm < > ?

First, #asm is really a way to change programming languages in
mid-stream. Second, kindly explain how #asm sections are portable?
Third, why not use separate assembly modules instead? If you _really_ need
the flexibility of assembly to do low-level programming, use an
assembler. I can see no need to mix assembly and C at the C source
level (why was the language designed in the first place?).

|...  Those who believe that the language gurus can
|_possibly_ anticipate how someone who understands the machine will want
|to do things are either totalitarian, ignorant, or stupid.

Agreed.
Of course, you are not suggesting that Doug is one of these, are you?

But let's go further on this point:
Those who believe that the language gurus can _possibly_ anticipate
how everyone (knowledgeable, ignorant, other) will want to do _any_
thing are ...

The language gurus themselves do not claim this.
A language is designed to perform a certain class of tasks - even the
class 'general', of which C is not a member. To even start to hope
that a non-machine specific language will produce *truly* optimal
code for other machine architectures is futile. Iff (not a typo) you
really must have use a machine's features for efficiency (which is
the point you argue [...understands the machine...]), drop down to that
machines optimal language, assembly. And do it in a file all by itself.

Do *not* mix languages in a single source file.

|I maintain that anyone who understands whatever computer is being programmed
|for will, without effort, see situations in which the HLL concepts (any HLL)
|are not the right way to do things.  This should be encouraged; progress in
|programming should no be based on "thou shalt not do this because
|	It can be done thusly (but not necessarily efficiently).
|	It can get you into trouble.
|	Why would anyone want to do this?"

I disagree. You presume that this same individual also knows how the HLL
implements itself on that machine. This is not the case. Very few people
that know both the HLL and the machine instruction set will know what kind
of code the compiler will produce.

What do you mean by 'progress in programming'?

True, it is unwise to place arbitrary restrictions upon a society
because the ruler-makers deem the masses incapable. (Follow this one
up to talk.flame, or wherever). In the context of programming, especially,
this has a deadening effect. However, for instructional purposes, a few
'thou shalt nots' are highly beneficial.
-- 
--------------------"Well, it looked good when I wrote it"---------------------
 Verbal: Dave Burton                        Net: ...!ihnp4!laidbak!daveb
 V-MAIL: (312) 505-9100 x325            USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h>                          Naperville, IL  60540