assembly in future C standard

[fermineutron]

Some compilers support __asm{ } statement which allows integration of C
and raw assembly code. A while back I asked a question about such
syntax and was told that __asm is not a part of a C standard. My
question now is:

Is there a chance that such statement will become a part of C standard
in the future? In some cases using asm language is the best way to
acomplish some small task, hence integration of C and asm would greatly
enhence C, or atleast it would in my opinion.

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

I have bumped into compilers that support and others that ignore __asm
statement so obviously it is still not a part of C standard.

[Gordon Burditt]

>No HCF?

>>
Where'd you get these anyway?

At first I thought that was a stupid question... but googling "tangle
tape and crash" turned up 64 hits. So, your question wasn't stupid;
there are at least 64 possible answers, and we have no way of knowing
which is correct until John responds!

BTW, googling "Punch Invalid" turns up a much longer list:
http://www.physics.ohio-state.edu/~b...ction.set.html
I do wonder if "Punch Invalid" had originally been a real error
message on a mainframe somewhere (relating to a broken or missing
cardpunch), and made it into these lists due to the double entendre. :)

Real OS/360 card readers had this error called a "validity check".
They had to read 1 column (with positions for 12 punches) and
translate this into a byte (8 bits), unless the cards were being
read in "column binary" mode (12 bits per column), which was rarely
used. Describing this as "Punch Invalid" was reasonable, since it
read an invalid combination of punches.

Naturally, with 4096 possible codes and only 256 valid ones (the
maximum number of punches for a valid column was 6, as in 12-11-0-7-8-9),
a lot of combinations were invalid, particularly the infamous
"ventilator column" (all 12 positions punched out) often appearing
on the "ventilator card" (all 12 positions X 80 columns punched
out, which weakened the card so much it was likely to jam, in both
card readers and keypunches).

If the card reader stopped with a validity check, you retrieved the card
with the error, put it first in the hopper, and started reading again.
If it kept doing it, you took the offending deck out, handed it back
to the person submitting it, and told them to fix it.

[Chris Dollin]

John Bode wrote:

I first saw that list back in '87 or '88, and I think a couple of
entries are missing (eXecute OPerator and eXecute OPerator Immediate
(20,000 volts to the console).

Similar lists existed before 1979 (I encountered one before I started
Paid Work). Possibly my favourite pair was Switch Off (boring) and
Switch On (less boring).

--
Chris "hashed up hashing" Dollin
"Who are you? What do you want?" /Babylon 5/

[Richard Bos]

"Rod Pemberton" <do*********@bitfoad.cmmwrote:

"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

Theoretically it seems possible to develop a subset of assembly
languages which are used by motern CPUs and include in a C standard a C
library which would allow user to use the assembly subset. Since it is
a limited subset and its sintax is goverened by C it should not present
portability challenges with possible exception of older systems. any
thoughts about this?

You should ignore any response Healthfield gives to your question.

This problem was solved in the very first assembly language:
http://en.wikipedia.org/wiki/Autocode

"Very first" is debatable; there were assemblers for the ENIAC. You may
or may not count these, depending on how you count.

In any case, that does not solve the OP's problem. It doesn't allow you
to use all the dirty tricks that you can use in native assembly
language, such as controlling the pipelining or addressing specific
hardware directly. OTOH, if you extend it so that you can use these
tricks, the result will ipso facto not be portable to all systems,
simply because the processor and hardware on other systems may not allow
you to pull the tricks you wanted to pull on the first system, and where
they do, may have different constraints.

It has also been solved by many other languages, the most effectively by
FORTH and C.

Ah. Yes. And there's the rub, isn't it? To the advocates of __asm, the
way it's been solved by C isn't effective enough. If it were, they'd use
C as it is, rather than asking for assembly language to be shoehorned
in. (Whether such advocates are correct in their desires is another
matter. IMO they're not.)

The above functionality of C can be represented by 16 "actions" and 20
arithmetic operations. That means that C can be written on an interpreter.
The highly portable QEMU emulator reduces host specific CPU instructions to
"micro-ops" for a virtual machine. Those "micro-ops" could be considered to
be a portable assembly. Research into the FORTH language, shows that the
_entire_ functionality of FORTH language (which is just as powerful as C)
reduces to 13 "primitives."

Amateurs.

<http://catseye.mine.nu:8080/projects/smetana/doc/smetana.html>. Two.
<http://catseye.mine.nu:8080/projects/thue/doc/thue.txt>. Three, if you
count Production, Input and Output, but unlike Smetana, known to be
Turing-complete. And if you only care about calculation and are willing
to write and read the data straight from the chip, you can reduce this
to a single primitive.

Richard

[Richard Bos]

Jordan Abel <ra****@random.yi.orgwrote:

John Bode wrote:

fermineutron wrote:

Theoretically it seems possible to develop a subset of assembly
languages which are used by motern CPUs and include in a C standard a C
library which would allow user to use the assembly subset. Since it is
a limited subset and its sintax is goverened by C it should not present
portability challenges with possible exception of older systems. any
thoughts about this?

Here's a proposed set:

No HCF?

No Sign Extend, either. I want my Sign Extend! Not to mention a Halt and
Terminate Operator instruction, although there are several which could
be used for roughly the same purpose.

Where'd you get these anyway?

The back of a C-Flat manual, I'd guess.

Richard

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

sj*******@yahoo.com a écrit :

jacob navia wrote:

>Assembly is quite portable between OSes, but not within
different processors

Seems like you're using an odd definition of "portable" here. On
common platforms assembly is not portable between different
compilers/assemblers on the same OS and architecture, let alone between
OSes. Certainly on a single architecture it's possible to write an
assembler that runs under many OSes, but having just one standard
assembly language even in one OS is _not_ the current state of the
world on everyday architectures--witness the x86 example I gave in the
message you replied to.

Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures.

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

[fermineutron]

And for aplications that run on machines connected to internet we can
have additional instructionl like

OP - Order Pizza
PSG - Port Scan Google

I also want an SFP instruction, so the the computer could Show Free
Porn. With todays grafix that should be possible.

[Rod Pemberton]

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:Oa******************************@bt.com...

Rod Pemberton said:

<snip>

>
If he were capable of giving good advice, he would probably also be

capable

of spelling my name correctly.

I'm sorry that I unintentionally mispelled of your name out of a

thousand

or
so. You know that I haven't mispelled it elsewhere.

You know that, and I know that, but the Google archives disagree with us
both.

I guess it was a
convenient excuse for you to ignore the fact that your response was
totally incorrect and borders upon incompetence.

I stand by the accuracy and correctness of my response.

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. Where's yours (just
like Bill Reid, do you have none)? I even forgot to mention a couple of the
best cases against your argument. I guess you can stand anywhere you want.
But, your attempt to claim that there is any accuracy or correctness of your
response is a blatant lie.
Rod Pemberton

[Rod Pemberton]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmmwrites:
"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...
Theoretically it seems possible to develop a subset of assembly
languages which are used by motern CPUs and include in a C standard

a C

library which would allow user to use the assembly subset. Since it

is

a limited subset and its sintax is goverened by C it should not

present

portability challenges with possible exception of older systems. any
thoughts about this?

You should ignore any response Healthfield gives to your question.
[snip]

That's really bad advice.

How so? It appears that your response is incorrectly biased...

Here's what Richard wrote:

| Would that it were true - but it isn't. There is no such thing as

"assembly
<snip>

Is that what you're referring to?

No. You're off by one level. Please, try to follow. I told "fermineutron"
to ignore any response to the question above that he posted. Heathfield's
response was posted prior to my statement. This is Heathfield's response to
the said question:

RHFeel free to try. Don't forget to include CPUs manufactured by Cray,
Unisys,
RHthe mainframe division of IBM, Analog, Motorola... and many many more
RHbesides. Once you see how long the list is, and how many different
assembly
RHlanguages with different syntaxes are out there, you'll realise why
nobody
RHis doing this

Heathfield's response was totally incorrect and borders upon

incompetence.

>
No, he was quite correct. If you disagree, by all means say so;
there's no need to make it personal.

No, he wasn't and still isn't. Reread the facts I posted to the contrary.
Rod Pemberton
..

[Rod Pemberton]

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

"Rod Pemberton" <do*********@bitfoad.cmmwrote:

"fermineutron" <fr**********@yahoo.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...

Theoretically it seems possible to develop a subset of assembly
languages which are used by motern CPUs and include in a C standard a

C

library which would allow user to use the assembly subset. Since it is
a limited subset and its sintax is goverened by C it should not

present

portability challenges with possible exception of older systems. any
thoughts about this?

You should ignore any response Healthfield gives to your question.

This problem was solved in the very first assembly language:
http://en.wikipedia.org/wiki/Autocode

"Very first" is debatable; there were assemblers for the ENIAC. You may
or may not count these, depending on how you count.

In any case, that does not solve the OP's problem. It doesn't allow you
to use all the dirty tricks that you can use in native assembly
language, such as controlling the pipelining or addressing specific
hardware directly. OTOH, if you extend it so that you can use these
tricks, the result will ipso facto not be portable to all systems,
simply because the processor and hardware on other systems may not allow
you to pull the tricks you wanted to pull on the first system, and where
they do, may have different constraints.

The only issue you mentioned that isn't supported by Autocode is pipelining.
Autocode even supports segmentation or multiple address spaces.

But, you're taking the issue of a "portable assembly" language and
attempting to turn it into a "comprehensive assembly" language. The two are
different. The full feature set of a CISC, and alomost VLIW, CPU such as
the x86 isn't needed to make a portable assembly language. And, the OP was
wanting a portable assembly language based on the functionality of C. I
listed that functionality. The functionality of C can be represented by 16
"actions" and 20 arithmetic operations. Even if one assumes that I'm
completely incorrect, say by 600% thereby giving C about minimum of 200
required operations, C could still be implemented as an interpreter. Those
16/20 (or 200) operations are the portable assembly he seeks.

It has also been solved by many other languages, the most effectively by
FORTH and C.

Ah. Yes. And there's the rub, isn't it? To the advocates of __asm, the
way it's been solved by C isn't effective enough.

For the OP, I believe it has been solved, because he wanted a C based
portable assembly. But, for the "advocates of __asm", it hasn't. C
captures the abilities of RISC, and most other early CPU's, but hasn't added
any additional complexity for CISC or VLIW CPU's, DSP's etc. Without __asm,
you need a kludge or extension to C to support segmentation, CPU registers,
etc. (see TR 18037: Embedded C, http://www.open-std.org/jtc1/sc22/wg14/).

If it were, they'd use
C as it is, rather than asking for assembly language to be shoehorned
in. (Whether such advocates are correct in their desires is another
matter. IMO they're not.)

They ask for assembly to be "shoehorned" in because extensions like TR18037
are about two decades _late_... Almost everything it adds has been in
needed and in use since the late '80's. I doubt the "original authors"
(knowing full well who they are) intended C to be a "dead" or static
language. So, now that everyone knows how to use __asm, instead of
extensions like TR18037, what is the point of extending C? (i.e., force
people to waste more time learning more C when they've already learned
assembly and it does the job?)

The above functionality of C can be represented by 16 "actions" and 20
arithmetic operations. That means that C can be written on an

interpreter.

The highly portable QEMU emulator reduces host specific CPU instructions

to

"micro-ops" for a virtual machine. Those "micro-ops" could be

considered to

be a portable assembly. Research into the FORTH language, shows that

the

_entire_ functionality of FORTH language (which is just as powerful as

C)

reduces to 13 "primitives."

Amateurs.

<http://catseye.mine.nu:8080/projects/smetana/doc/smetana.html>. Two.
<http://catseye.mine.nu:8080/projects/thue/doc/thue.txt>. Three, if you
count Production, Input and Output, but unlike Smetana, known to be
Turing-complete. And if you only care about calculation and are willing
to write and read the data straight from the chip, you can reduce this
to a single primitive.

Both of those appear to be theoretical. I listed Frank Sargent's 3
instruction FORTH which is an actual working FORTH using only 3 instructions
for embedded environments. In this case, the assembly instructions and
FORTH primitives were the same.
Rod Pemberton

[Rod Pemberton]

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

jacob navia <ja***@jacob.remcomp.frwrote:

sj*******@yahoo.com a écrit :

jacob navia wrote:
>
>>Assembly is quite portable between OSes, but not within
>>different processors
>
Seems like you're using an odd definition of "portable" here. On
common platforms assembly is not portable between different
compilers/assemblers on the same OS and architecture, let alone

between

OSes. Certainly on a single architecture it's possible to write an
assembler that runs under many OSes, but having just one standard
assembly language even in one OS is _not_ the current state of the
world on everyday architectures--witness the x86 example I gave in the
message you replied to.
>

Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures.

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

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

Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures. That is
why lcc-win32 uses ATT syntax and NOT Intel's syntax.

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

[Richard Heathfield]

Rod Pemberton said:

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:Oa******************************@bt.com...

<snip>

>>
I stand by the accuracy and correctness of my response.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[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
-------
1 + 1 = 3, for large values of 1.

[jacob navia]

Rod Pemberton a écrit :

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

>>jacob navia <ja***@jacob.remcomp.frwrote:

>>>sj*******@yahoo.com a écrit :

jacob navia wrote:
>Assembly is quite portable between OSes, but not within
>different processors

Seems like you're using an odd definition of "portable" here. On
common platforms assembly is not portable between different
compilers/assemblers on the same OS and architecture, let alone

between

>>>>OSes. Certainly on a single architecture it's possible to write an
assembler that runs under many OSes, but having just one standard
assembly language even in one OS is _not_ the current state of the
world on everyday architectures--witness the x86 example I gave in the
message you replied to.
Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures.

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

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

>>Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures. That is
why lcc-win32 uses ATT syntax and NOT Intel's syntax.

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 :

jacob navia <ja***@jacob.remcomp.frwrote:

>>sj*******@yahoo.com a écrit :

>>>jacob navia wrote:
Assembly is quite portable between OSes, but not within
different processors

Seems like you're using an odd definition of "portable" here. On
common platforms assembly is not portable between different
compilers/assemblers on the same OS and architecture, let alone between
OSes. Certainly on a single architecture it's possible to write an
assembler that runs under many OSes, but having just one standard
assembly language even in one OS is _not_ the current state of the
world on everyday architectures--witness the x86 example I gave in the
message you replied to.

Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures.

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.

[Bob Martin]

in 703970 20061102 112007 jacob navia <ja***@jacob.remcomp.frwrote:

>Rod Pemberton a écrit :

>"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

>>>jacob navia <ja***@jacob.remcomp.frwrote:
sj*******@yahoo.com a écrit :

>jacob navia wrote:
>
>
>>Assembly is quite portable between OSes, but not within
>>different processors
>
>Seems like you're using an odd definition of "portable" here. On
>common platforms assembly is not portable between different
>compilers/assemblers on the same OS and architecture, let alone

between

>>>>>OSes. Certainly on a single architecture it's possible to write an
>assembler that runs under many OSes, but having just one standard
>assembly language even in one OS is _not_ the current state of the
>world on everyday architectures--witness the x86 example I gave in the
>message you replied to.
>

Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures.

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

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

>>>Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures. That is
why lcc-win32 uses ATT syntax and NOT Intel's syntax.

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

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]

jacob navia wrote:

>

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

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Flash Gordon]

Bob Martin wrote:

in 703970 20061102 112007 jacob navia <ja***@jacob.remcomp.frwrote:

>Rod Pemberton a écrit :

>>"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

jacob navia <ja***@jacob.remcomp.frwrote:
sj*******@yahoo.com a écrit :
>
>jacob navia wrote:
>>
>>
>>Assembly is quite portable between OSes, but not within
>>different processors
>Seems like you're using an odd definition of "portable" here. On
>common platforms assembly is not portable between different
>compilers/assemblers on the same OS and architecture, let alone
between

>OSes. Certainly on a single architecture it's possible to write an
>assembler that runs under many OSes, but having just one standard
>assembly language even in one OS is _not_ the current state of the
>world on everyday architectures--witness the x86 example I gave in the
>message you replied to.
>>
Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures.
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.)
You're responding to the wrong stuff. You snipped the important part of his
statement. So, let's back it up:
Since Mac OS, Windows, Linux and Solaris all run the gcc compiler
and since that compiler has an assembler, using that assembler
makes your code portable to any of those architectures. That is
why lcc-win32 uses ATT syntax and NOT Intel's syntax.

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

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

[Andrew Poelstra]

On Thu, 2006-11-02 at 09:08 -0500, CBFalconer wrote:

jacob navia wrote:

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

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.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

[james of tucson]

Andrew Poelstra wrote:

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]

2006-11-02 <7D****************@newsfe15.phx>,
james of tucson wrote:

Andrew Poelstra wrote:

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

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

[Walter Roberson]

In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:

>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.
--
Programming is what happens while you're busy making other plans.

[CBFalconer]

Andrew Poelstra wrote:

On Thu, 2006-11-02 at 09:08 -0500, CBFalconer wrote:

>jacob navia wrote:

>>>

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

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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Andrew Poelstra]

On Thu, 2006-11-02 at 09:01 -0700, james of tucson wrote:

Andrew Poelstra wrote:

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.

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.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

[james of tucson]

Andrew Poelstra wrote:

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]

Rod Pemberton <do*********@bitfoad.cmmwrote in message
news:ei**********@ltw.loris.tv...

>

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"!

---
William Ernest Reid

[Richard Heathfield]

Andrew Poelstra said:

On Thu, 2006-11-02 at 09:01 -0700, james of tucson wrote:

>Andrew Poelstra wrote:

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.

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[james of tucson]

Richard Heathfield wrote:

Andrew Poelstra said:

>On Thu, 2006-11-02 at 09:01 -0700, james of tucson wrote:

>>Andrew Poelstra wrote:

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.

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

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]

in 704146 20061103 071302 Richard Heathfield <in*****@invalid.invalidwrote:

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

in 704146 20061103 071302 Richard Heathfield <in*****@invalid.invalid>
wrote:

>>
That too. Try running cygwin on a 4341. :-)

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

So I can blame you, then? :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Walter Banks]

As this thread wanders off topic this industry was introduced to a new
mnemonic in Byte article about decoding the undocumented
Motorola 6800 instructions. The HCF (Halt Catch Fire) opcode $DD
or $D9. HFC locked up the processor and cycled the address bus
The author of that article was Gerry Wheeler.

Gerry Wheeler, 54, died October 15, 2006, advanced non-Hodgkins
lymphoma cancer. Gerry made significant contributions to the technology
of the embedded systems world and was a key part of the development
of many household name products.

Programmer, Ham KG4NBB, author, father, husband, active commuity
participant Gerry will be missed by all.

w..

[Andrew Poelstra]

On Fri, 2006-11-03 at 07:13 +0000, Richard Heathfield wrote:

Andrew Poelstra said:

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

That too. Try running cygwin on a 4341. :-)

The closest I got was running Linux on a Linksys WRT54GL router and an
iPod. There was also that foray into NES assembler, but that ended with
a lack of EEPROM hardware.

--
Andrew Poelstra <http://www.wpsoftware.net>
For email, use 'apoelstra' at the above site.
"You're only smart on the outside." -anon.

[Chris Thomasson]

"Chris Torek" <no****@torek.netwrote in message
news:ei********@news3.newsguy.com...

In article <vc******************************@comcast.com>
Eric Sosman <es*****@acm-dot-org.invalidwrote:

> A more usual motivation is to make use of special machine
instructions the compiler would not generate on its own.

[...]

I agree with all of this; however, in some (sometimes significant)
cases (e.g., the actual implementation for a mutex), you may want
to have an inline expansion of the underlying atomic operation,
typically via a macro. For instance, if you have a mutex construct
that -- at least in the uncontested case -- is just a (possibly
locked) compare-and-swap, you may want the x86-specific version
of:

[...]

The tricky part lies not only in arranging for the assembly equivalent
to be inserted inline, but in *also* informing the compiler that
it must not move certain memory operations across the "special"
instruction(s).

[...]

Indeed!

http://groups.google.com/group/comp....f096adecdd0369
(refer to the last couple of paragraphs...)

;^)


FWIW, in order to correctly implement this kind of stuff, you simply have to
define exactly how you are going to address two fundamental problems:
1: Compiler Reordering
2: Hardware Reordering


--1-- The compiler reordering issue can "usually" be resolved by strictly
adhering to a design policy which declares that all functions that contain
"critical-sequences" of instructions that have to be executed in precise
order must be externally assembled. This is due to the current fact that the
C Standard doesn't think threads even exist. However, an Assembler is a
different story IMO simply because it gives you full access to the
architecture your targeting and it will not reorder any your assembly
statements; what you see is exactly what you get.

IMO, a typical C compiler is usually forced to treat any call into an
"unknown and external" function in a fairly "pessimistic" manor", which in
turn basically renders its behavior to something that is analogous to a
so-called "compiler barrier". However, please note that some compilers are
exploring link-time optimizations which can, and probably will, turn out to
be an annoying and potentially hazardous scenario to any function that
simply expects every instruction its made up of will be executed exactly
as-is. Period. Unfortunately, this definitely includes basically all
externally assembled functions that a lock-free library may export by
default.

;^(...
However, all is not list because it does seem like the compilers that do
support link-time optimizations' also provide some method for turning it
on/off. Usually, they allow you to decorate your "critical-function"
declarations with something that guarantees that they will never be
subjected to this particular type of optimization.


--2-- Hardware reordering is easily solved by placing the proper the memory
barrier instructions in the correct places throughout your externally
assembled lock-free library. The assembler won't reorder any instructions,
therefore, this is the only real solution wrt actually implementing this
kind of stuff.


Therefore, it is my theses that a safe method for ensuring that calls into
"critical-function" will not be tampered with must include a combination of
solutions that directly resolve all of the reordering issues that are
attributed to both the hardware your targeting, and the C compiler your
using...

Any thoughts?

[...]

The compiler may think the second version is superior (because it
uses less CPU time overall, e.g., due to reduced register pressure
or because it schedules better), but in fact, it is not. :-)

;^)

[Markus.Elfring]

--1-- The compiler reordering issue can "usually" be resolved by strictly

adhering to a design policy which declares that all functions that contain
"critical-sequences" of instructions that have to be executed in precise
order must be externally assembled. This is due to the current fact that the
C Standard doesn't think threads even exist. However, an Assembler is a
different story IMO simply because it gives you full access to the
architecture your targeting and it will not reorder any your assembly
statements; what you see is exactly what you get.

I imagine that optimizing assembler implementations might exist that
break your expectation.
http://en.wikipedia.org/wiki/Assembly_language

Which pragmas or flags would you like to present to those specific
compiler tools to keep the specified instruction sequence until it will
be put into an executable file by an also optimizing linker?

I guess that such tools do not provide the guarantees that are required
for program correctness so far.

IMO, a typical C compiler is usually forced to treat any call into an
"unknown and external" function in a fairly "pessimistic" manor", which in
turn basically renders its behavior to something that is analogous to a
so-called "compiler barrier". However, please note that some compilers are
exploring link-time optimizations which can, and probably will, turn out to
be an annoying and potentially hazardous scenario to any function that
simply expects every instruction its made up of will be executed exactly
as-is. Period. Unfortunately, this definitely includes basically all
externally assembled functions that a lock-free library may export by
default.

I assume that the compiler barrier can be unsafe and fragile.
Portability will only be limited to some system environments.
There are so many preconditions to consider.

Regards,
Markus

[Chris Thomasson]

<Ma************@web.dewrote in message
news:11**********************@f16g2000cwb.googlegr oups.com...

>--1-- The compiler reordering issue can "usually" be resolved by
strictly
adhering to a design policy which declares that all functions that
contain
"critical-sequences" of instructions that have to be executed in precise
order must be externally assembled. This is due to the current fact that
the
C Standard doesn't think threads even exist. However, an Assembler is a
different story IMO simply because it gives you full access to the
architecture your targeting and it will not reorder any your assembly
statements; what you see is exactly what you get.

I imagine that optimizing assembler implementations might exist that
break your expectation.
http://en.wikipedia.org/wiki/Assembly_language

[...]

Here is my response:

http://groups.google.com/group/comp....9fe7e6a5b23de0

This is more topic in c.p.pt anyway: Optimizing assembler doesn't exist;
suspiciously sounds like C compiler anyway...

[Dave Thompson]

On 29 Oct 2006 08:45:11 -0800, "fermineutron" <fr**********@yahoo.com>
wrote:
<snip>

By the way, returning to the minimal list of cpu instructions, i thing
that thre true bare bone will have 2 instructiions, Move and Add. Move
can be used to read and write, whie add can be used to to addition,
subtraction, multiplication and division. Shift instructions would
speed it up, but are redundant. So if C is to be truly compatible
whith anything and everything, should not it limit the compiler output
to these 2 instructions. Obviously its an overkill, but gets my point
across.

Actually that's neither necessary nor sufficient.

Add by itself cannot build negate, subtract, and divide, but subtract
can build add (and multiply) and compare.

You need some kind of transfer of control; you can use move (or add)
for this if (and only if) you make the PC addressable as a register
(e.g. PDP-11) or put it in memory (I think some early machines did
this); or you can have explicit successors (as I know some did). And
you need some kind of conditional operation. If by move vs add you
mean the RISC-style division between memory reference instructions and
in-CPU-only computation ones, yes you need both; but if you have a
common but general format you can use ADD-zero for move. In fact a
common and practical RISC technique is not to waste an ALU code for
move rega to regb, just have a general three-address format and a zero
operand and OR rega with zero to regb or ADD rega plus zero to regb.

But those functions needn't be in separate instructions. The "one
instruction set computer" architecture -- there's a website somewhere
I've forgotten -- is something like "decrement and jump if zero". Then
you don't need an opcode field at all, your instruction (format)
consists entirely of address fields. But it's about as hugely and
gloriously inefficient as a (conventional) universal Turing machine,
so no consumer would ever buy one to use for anything, which rather
limits the market for programs written on it.

And that (kind of limitation) isn't what we C folks want.

- David.Thompson1 at worldnet.att.net