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

[Herman Rubin]

In article <1355 at laidbak.UUCP>, daveb at laidbak.UUCP (Dave Burton) writes:
> 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?).

Frankly, I believe that if someone developed a decent high-level, overloaded
operator, reasonable syntax assembler it would have a good chance of
supplanting C.  Add the other useful features of C and you have a good
language.

Suppose that you have a situation in a program where the implementation of
your compiler has done something bad, like use 10 instructions and 6 memory
references where 2 instructions and no memory references can do the job.
The overhead of a subroutine call is likely to be more than what can be
saved; a goto construction may not work if part of the problem is that the
compiler will mess up register use (very common).

Also some of the very simple hardware operations which are useful for some
problems have not been anticipated by the language developlers.  This is so
often the case for simple operations frequently found in hardware.  More
machines have a hardware operation &~, which most mathematicians normally
use \ for, than have the operation &.  I am more likely to want to use &~.
If a programmer says that something is inline, and this should be a feature
of any language, the compiler should at most point out why this is not good,
but the judgment must be that of the programmer.


> 
> |...  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.

The language gurus may not claim this, but I am not so sure.  The 
designers of 4.xBSD clearly state in their assembler documentation
that the assembler is _not_ for programmers, but for compiler designers
and system maintainers.  All of the assemblers I have seen, with the 
exception of those designed for Cray-designed machines, use the atrocious
prenex form with highly obfuscated ordering of arguments.  In the early days
of computers, this may have been necessary.

I consider a programming language and an operating system to be a procedure
whereby the user is enabled to more easily use the power of the computer.
It is a great mistake to restrict a programming language.

	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.

But in too many cases, the existing HLLs may produce good code if small
modifications are made.  In many cases, these modifications are machine
independent--I can give you cases of this.  It may even be as simple as
saying
	This is what is needed; implement this block efficiently, while
	maintaining its compatibility with the rest of the program.

That is another reason for asm.

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

See above.


> 
> |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.

Why not?

> 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.

I see the results of students instructed by algorithms.  Admittedly, these
are not CS algorithms, they are mathematics algorithms.  I find that most of
them seem incapable of understanding the few simple concepts behind the 
algorithms.  I believe that this applies to computing as well.

-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin at l.cc.purdue.edu (ARPA or UUCP) or hrubin at purccvm.bitnet