assembly in future C standard

[Richard Heathfield]

Rod Pemberton said:

You weren't qualified to respond, but you did so anyway, provided a
ludricrously false response, and expected everyone here to accept it as
truth? As an example of falseness of your response, I provided facts,
statistics, and proof, which contradicted your claims.

No, you didn't. I'm not sure what you think you were contradicting, but it
isn't anything I said.

 

[jacob navia]

Rod Pemberton a écrit :

You're responding to the wrong stuff. You snipped the important part of his
statement. So, let's back it up:




He stated, albeit less than elegantly, that he uses the gcc assembler as a
back-end to lcc-win32 because the gcc assembler supports multiple targets.


Rod Pemberton

No, I do not use any gcc software, but lcc-win32's assembler
uses the same SYNTAX as gcc's assembler.

And for the poster that complains about assembly language not being
portable, what is portable is the same processor, not the interrupts,
not the calls to some specific procedure. Portable assembly is,
for instance, a package to calculate with floats 350 bits
wide, or another package to implement bignums. Those packages do not
use any OS dependent features, and even if written entirely
in assembly language they are portable to any OS that supports the
same processor.

jacob

 

[jacob navia]

Richard Bos a écrit :

Oh, right? So calling interrupt 20h will do the same thing under MS-DOS
that it does under MS-Windows? Int 13 can be used to read the disk
allocation tables under Linux? Or are you perhaps limiting yourself to a
severely restricted sub-set of that assembly code?
(Note also that you contradict yourself, since MacOS, MS Windows, and
Solaris may all sometimes use gcc, they typically run on different
processors; so according to your previous post, quoted above, assembly
would not be portable across those three, while here you claim that it
should be.)

Richard

What is portable is the same processor opcodes, not the interrupts,
not the calls to some specific procedure. Portable assembly is,
for instance, a package to calculate with floats 350 bits
wide, or another package to implement bignums. Those packages do not
use any OS dependent features, and even if written entirely
in assembly language they are portable to any OS that supports the
same processor.

The inputs are standard, the outputs are well defined, they are portable
across any processor that implements the x86 instruction set.

Obviously interrupts (supervisor calls, system() etc)are not portable.

This is the same as C. C is portable but
system("ls");
will work in Unix and not in windows.

 

[Andreas Kochenburger]

Is there a good reason why __asm is not a part of current C standard?

Because asm is not C, thus not part of the C language specification.

Linking is also not part of the standard. Since you can create object
files with external assemblers and link them with your C code, there
is no need for over-standardization.



Andreas

 

[Bob Martin]

Rod Pemberton a écrit :

No, I do not use any gcc software, but lcc-win32's assembler
uses the same SYNTAX as gcc's assembler.

And for the poster that complains about assembly language not being
portable, what is portable is the same processor, not the interrupts,
not the calls to some specific procedure. Portable assembly is,
for instance, a package to calculate with floats 350 bits
wide, or another package to implement bignums. Those packages do not
use any OS dependent features, and even if written entirely
in assembly language they are portable to any OS that supports the
same processor.

jacob

Your last sentence sums up the flaw in your argument. The Intel processors
are not the be-all and end-all of computing. More code is written for non-Intel
processors than for Intel. Code that is "portable" to less than 50% of applications
does not deserve the label.

You should widen your horizons. Have you done any mainframe programming?

 

[CBFalconer]

.... snip ...

This is the same as C. C is portable but
system("ls");
will work in Unix and not in windows.

Oh? It works fine here under W98.

[1] c:\c\factsize>ls
a.exe a.out factsize.bak factsize.c factsize.exe factsize.o

[1] c:\c\factsize>lsl
total 260
-rwxr-xr-x 1 dosuser 86866 Sun Oct 08 23:33:16 2006 a.exe
-rwxr-xr-x 1 dosuser 84818 Sun Oct 08 23:33:14 2006 a.out
-rw-r--r-- 1 dosuser 839 Sun Oct 08 23:33:06 2006
factsize.bak
-rw-r--r-- 1 dosuser 839 Sun Oct 08 23:34:00 2006
factsize.c
-rwxr-xr-x 1 dosuser 86735 Sat Oct 07 12:17:42 2006
factsize.exe
-rw-r--r-- 1 dosuser 4310 Sun Oct 08 23:26:42 2006
factsize.o

 

[Flash Gordon]

Your last sentence sums up the flaw in your argument. The Intel processors
are not the be-all and end-all of computing. More code is written for non-Intel
processors than for Intel. Code that is "portable" to less than 50% of applications
does not deserve the label.

You should widen your horizons. Have you done any mainframe programming?

It's worse that you pain. Not all x86 systems are programmed using the
same assembler syntax (as Jacob admitted), so at the source level it is
not portable to all x86 systems. Not all x86 systems use the same object
format, so it's not portable to all x86 systems at the object level.
Then we get on to the mess of calling conventions, since not everything
for the x86 uses the same calling conventions. So it is far from
portable to all x86 systems without even starting to wonder about which
processors in the series it supports, since I know there are still 8086
and 80186 systems out there in real use, although I'm no longer in a
position to know if any development is being done for them.

 

[Andrew Poelstra]

Oh? It works fine here under W98.

Not over here under Media Center or Blister RC2.

The chances of someone installing UNIX tools on their system seems
lower than that of them installing cgywin or just plain Linux. And
both of those chances are still pretty low right now.

 

[james of tucson]

The chances of someone installing UNIX tools on their system seems
lower than that of them installing cgywin or just plain Linux. And
both of those chances are still pretty low right now.

Chances? Anybody that wants to is free to run cygwin or linux. That's
the whole point. I don't see where there is any chance involved.

 

[Jordan Abel]

Chances? Anybody that wants to is free to run cygwin or linux. That's
the whole point. I don't see where there is any chance involved.

Chance can be used as another term for probability. The probability that
any given user has done so is low.

 

[CBFalconer]

Not over here under Media Center or Blister RC2.

The chances of someone installing UNIX tools on their system seems
lower than that of them installing cgywin or just plain Linux. And
both of those chances are still pretty low right now.

Not UNIX tools, just DJGPP. Simple. Most unixy things just work.

 

[Walter Roberson]

And for the poster that complains about assembly language not being
portable, what is portable is the same processor, not the interrupts,
not the calls to some specific procedure. Portable assembly is,
for instance, a package to calculate with floats 350 bits
wide, or another package to implement bignums. Those packages do not
use any OS dependent features, and even if written entirely
in assembly language they are portable to any OS that supports the
same processor.

I'm almost sure we went over this before??

You are assuming that just because two systems support the same
processor, that they support the same assembly language. That is
manifestly false. There are an amazing number of different and
incompatible assemblers for systems in the Motorola 68000 line,
and similarily for several of the MIPS processors (both have been
fairly popular in the embedded processor market.)

Let me give a concrete example: SGI's IRIX, the assembler changed
greatly (different software company, different processor status
word setup, different calling conventions, different object file
format, different symbol table format) between IRIX 5.3 and IRIX
6.0, and yet both assemblers supported the MIPS R3000 CPU.

You are also assuming that any two systems with the same processor
will use the processor the same way. Bad assumption. It is common
for processors to be designed to support a number of different
memory models (especially different cache sizes), with the
actual cache size to be used being retrieved via pins at power-up
time. There are CPUs that are designed to be able emulate
several different brands of CPUs, possibly even switching emulations
for different programs. And there are entire CPU families such as
MIPS that can be used in either "big endian" or "little endian" mode,
with the mode hardwireable (if so desired) or changable via a
processor control bit (for those systems that so desire.) In each
of these cases, even if the *same* assembler was used for the same
processor, the program could end up incompatible because of very
small differences in the hardwiring of the CPU setup.

 

[Keith Thompson]

And for the poster that complains about assembly language not being
portable, what is portable is the same processor, not the interrupts,
not the calls to some specific procedure. Portable assembly is,
for instance, a package to calculate with floats 350 bits
wide, or another package to implement bignums. Those packages do not
use any OS dependent features, and even if written entirely
in assembly language they are portable to any OS that supports the
same processor.

Sheesh!

Portability to a single processor, or to a single processor family,
*is not portability*.

If you want to do stuff that will only work on an x86, feel free to do
so, but please find someplace else to talk about it. We discuss
standard C here.

 

[Andrew Poelstra]

Chances? Anybody that wants to is free to run cygwin or linux. That's
the whole point. I don't see where there is any chance involved.

The chances that they know they can, then. Or the chances that
they're willing, or allowed to. (Perhaps they're at school and
are using public computers on which they have no administrative
permissions).

People in general haven't figured out that all the world ain't
a Wintel.

 

[james of tucson]

The chances that they know they can, then. Or the chances that
they're willing, or allowed to.

Specify that it's required, and then it's their problem.

 

[Bill Reid]

This is the most brilliant part of this latest troll:

your response was totally
incorrect and borders upon incompetence.

He won't
find anything even remotely close in hundreds, if not thousands, of
programming books.

Behold the beauty of this insane troll logic. It is a glittering diamond of
unassailable non-reason that can be used for any topic. A few examples:

"The Earth isn't round, or flat, but kind of a twisted toroidal donut
shape with a 7000 mile hole in the center. You won't find anything
even remotely like that in hundreds, even thousands of geology
books; therefore, you are an incompetent geologist if you don't
know this!"

"The United States was formed when it fought the Reactionary
War to free itself from China in 1927. You won't find anything
even remotely like that in hundreds, even thousands of American
history books; therefore, you are an incompetent historian if you
don't know this!"

Architecture, art, astronomy, right on down to zoology, the entire
sum of human knowledge and all constructive endeavors, can be brought
to their collective knees with a single mighty blow from this lunatic
tactic of epic genius. Bravo! Troll on, "Rod"!

 

[Richard Heathfield]

Andrew Poelstra said:

The chances that they know they can, then. Or the chances that
they're willing, or allowed to. (Perhaps they're at school and
are using public computers on which they have no administrative
permissions).

Or perhaps they're working in a company which likes to keep careful control
over what software is installed on its computers, for legal and safety
reasons. Almost all the companies I've worked for in the UK are like this.

People in general haven't figured out that all the world ain't
a Wintel.

That too. Try running cygwin on a 4341.

 

[james of tucson]

Andrew Poelstra said:


Or perhaps they're working in a company which likes to keep careful control
over what software is installed on its computers, for legal and safety
reasons. Almost all the companies I've worked for in the UK are like this.


That too. Try running cygwin on a 4341.

Well, in that case, *definitely* don't deliver something to them that
requires Cygwin.

I still don't see what the problem is.

 

[Bob Martin]

That too. Try running cygwin on a 4341.

The 4341 was a great machine (I was a test engineer on the build line).

 

[Richard Heathfield]

Bob Martin said:

The 4341 was a great machine (I was a test engineer on the build line).

So I can blame you, then?