Re: assembly in future C standard

Richard Bos a écrit :
jacob navia <jacob@xxxxxxxxxxxxxxxx> wrote:


sjdevnull@xxxxxxxxx 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.
.

Relevant Pages

  • Re: Assembler syntax/instructions for different architecures and assemblers?
    ... Assembler, Netwide Assembler, TASM, etc.). ... written for ARM architecture with NASM? ... don't believe there is (nasm only really targeting x86 and variants). ...
    (alt.lang.asm)
  • Re: Moving from 8051 to AVR
    ... If you have sigificant amount of code written in assembler, ... you are locked into that architecture. ... porting it to an AVR was an even less smart thing to do. ... I would agree but the problem is you start with a nice small 8 bit MCU ...
    (comp.arch.embedded)
  • Re: Assembler syntax/instructions for different architecures and assemblers?
    ... The assembly code syntax is different for different assemblers (Gnu ... Assembler, Netwide Assembler, TASM, etc.). ... written for ARM architecture with NASM? ...
    (alt.lang.asm)
  • Re: Question on ProDOS SmartPort drive remapping
    ... assembler which generated two bytes of executable code: ... address on entry is stored in register 14. ... It was unavoidable for an architecture that introduced so many ... registers, long base registers with short instruction displacements, ...
    (comp.sys.apple2)
  • Re: GNU toolchain + ARM options
    ... My best guess at what is happening is that when you compile with no options ... the code generated by GCC itself is for ARMv4 or somesuch. ... assembler is allowing any version of the architecture. ...
    (comp.sys.arm)