Re: for your languages

On 2011-06-02, Rui Maciel <rui.maciel@xxxxxxxxx> wrote:
Seebs wrote:
Well, it will tie someone to a particular machine until someone invests
his time developing a compiler which is able to abstract that and, by
doing that, support other machines. After all, the language isn't the
compiler and the compiler isn't the language.

This really makes no sense. No abstraction of
xor ax,ax
makes sense.

Tell me this: is it impossible to perform that specific operation, either
through a single instruction or through a set of instructions, in two
different architectures?

Not in general, no.

Look at it this way: How would you do that on one of the Cell's SPE
units? Or, heck. PowerPC. What exactly is the equivalent of
xor ax,ax
on PowerPC?

Answer, there isn't one, *because there is no such thing as ax*. The PowerPC
chip does not have the same map of registers.

Similarly, let's say we start with some 68k assembly.

moveq #0,d0
moveq #0,d1
moveq #0,d2
moveq #0,d3
moveq #0,d4
moveq #0,d5
moveq #0,d6
moveq #0,d7

You can't translate this to x86, because x86 doesn't HAVE eight general
purpose data registers like that. (And if my memory's wrong, and it does,
no problem; just pop over to SPARC or something where there's even MORE
general purpose registers.)

If it is possible then it is also possible to
express that operation through an assembly language which supports both
architectures.

But it's not possible, because the entire point is that the architectures
DON'T have corresponding elements.

Please explain how you'd abstract
eieio
from a PPC macro assembler to something else...

If the processor architecture doesn't support out of order execution then
it can be omitted. If the target architecture supports it but doesn't
provide a way to enforce in-order execution then there could be a problem,
but I'm not aware of such a case.

There's a lot more to it than that. The semantics are not as simple as
a quick summary might make it sound.

The point of using assembly is that it lets you do things which simply
*don't* map to other chips. Say you're on an x86, and you're in segmented
mode. There's *nothing* you can do on a 68k that is even analagous to the
trickery that goes on when you take advantage of overlapping segments on
x86.

So, really, that's where this all breaks down; in reality, assembly code
is full of things which simply do not translate. That's why people use
it; because there's no way to express these things except in terms of a
given CPU. What bits might be set outside of the directly affected registers
by an operation? Different bits on different CPUs for different operations,
and the registers they'd be set in aren't necessarily translateable.

And this is why you can't meaningfully talk about an assembler being
portable in the way that C is. Fundamentally, C is specifying *semantics*,
which are an abstraction that need not correspond to specific processor
events. There are operations in C that generate no code on one machine
and lots of code on another, because the "function" described is irrelevant
in one system and complicated in another. Assembly, by contrast, is
specifying *instructions*. They don't necessarily have semantic content
that is comprehensible in any way separate from the details of that specific
chip. If you execute an instruction to "clear condition code register", that
doesn't necessarily translate to a machine which has more than one such
register, using them for different things. You can't talk about the
semantics of the code and translate at that level, because the code hasn't
*got* abstract semantics.

The closest you could come would be to write an entire processor simulator
and then just assemble the code. This clearly leaves us with a gigantic
difference between C and a "macro assembler".

-s
--
Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@xxxxxxxxx
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.
.

Relevant Pages

  • Intel Syntax Problems.
    ... > I think AT&T x86 assembler language makes a whole lot more sense than ... > doesn't care what language it emits. ... CPUs of that era, that supported overlapped 8/16 bit registers, you'll ... Once they had added BYTE PTR and ASSUME to the ...
    (alt.lang.asm)
  • Re: Jit Implementation
    ... dynamicism of an interpreted language. ... the assembler proper. ... this prompted me originally to start on a C compiler, ... However, it has fewer registers: just one main register, plus one or two ...
    (comp.compilers)
  • Re: assembly language and reverse engineering
    ... we are forced into using 32 bit registers, ... likewise, compiler code with a 32 bit version of MSVC, and link with a DOS ... the stack alignment is 2 bytes; ... 'normal' assembler code is more like, ...
    (alt.lang.asm)
  • Re: Auto-preservation of non-volatile registers by inline assembler
    ... is that on Windows the gp registers are pretty much ... Doing 'test reg, reg' ... GCC translates HLL sources to assembler files. ... the compiler does 'behind your back'. ...
    (comp.lang.asm.x86)
  • Re: Linux is as buggy as Windows
    ... registers for the Dx, ... it appeared to be somewhere around PDP11, ... Moveq, did not have Suba, and ... What is "The Ultimate Meme"? ...
    (comp.security.misc)