Assembly, C++ and a little more...
Pages: 12
Xenouis seems to be making a valid point. There is no reason why there shouldn't be a standard syntax for inline assembly. Instruction sets have little to do with this. Current methods are needlessly ugly.
Though I suppose separating C++ from asm entirely (as you would do with any other two languages) is the best idea.
Though I suppose separating C++ from asm entirely (as you would do with any other two languages) is the best idea.
closed account (1vRz3TCk)
How could you possibly specify a standard syntax for a group of languages that are external?
An assembly language is defined by instruction syntax, instruction set and extensions (I mean macros). Am I missing something? Pick one syntax, one (or none) extension and leave the instruction set for your compiler to decide. And before you say something about portability,
1. it's a lot more portable than what is currently available.
2. how often do you compile the same code on several architectures?
3. you can still use #ifdefs, only now you'll need fewer of them.
1. it's a lot more portable than what is currently available.
2. how often do you compile the same code on several architectures?
3. you can still use #ifdefs, only now you'll need fewer of them.
An assembly language is only one step up from machine language -- it gives you very few idioms above what pure machine language does.
If you want something more portable than "processor X assembly language" then you use a language like C or C++.
Whether or not Xenouis likes it -- or whether you like it, for that matter -- there is simply no way to make a "portable (cross-architecture) assembly language"; the concept is nonsense.
I understand his annoyance at having to deal with multiple assembler syntaxes targeting the same architecture, but again, you are wasting your breath. Some people hate Intel syntax while others hate GAS syntax. (Obligatory comic: http://xkcd.com/927/ )
GCC, obviously, prefers the GAS syntax, and uses it as much as possible.
If you want something more portable than "processor X assembly language" then you use a language like C or C++.
Whether or not Xenouis likes it -- or whether you like it, for that matter -- there is simply no way to make a "portable (cross-architecture) assembly language"; the concept is nonsense.
I understand his annoyance at having to deal with multiple assembler syntaxes targeting the same architecture, but again, you are wasting your breath. Some people hate Intel syntax while others hate GAS syntax. (Obligatory comic: http://xkcd.com/927/ )
GCC, obviously, prefers the GAS syntax, and uses it as much as possible.
I don't care about portability. Just how others before me didn't care about it, before it was an issue.
closed account (1vRz3TCk)
If you had a 'built-in' assembly language syntax then the compiler would have to covert what you had written to what the external assembler would require. This would put an unnecessary burden on the compiler vendor.
@Duoas, CodeMonkey, you make good points. Though it would be nice if you replaced 'impossible' with 'impractical'.
That would be the difference between 'true' and 'mostly true'.
Machine architectures vary significantly -- it is not just a matter of viewing it in terms of similarities; they actually work differently at the most basic level for the programmer.
Even something as simple as x86 vs MIPS is sufficiently different to make some fancy über-assembly a pipe dream.
Machine architectures vary significantly -- it is not just a matter of viewing it in terms of similarities; they actually work differently at the most basic level for the programmer.
Even something as simple as x86 vs MIPS is sufficiently different to make some fancy über-assembly a pipe dream.
closed account (43RGz8AR)
@Duoas I was not stating that I think there should be portable assembly, just a syntax so that C/C++ is complete with the way you write inline assembly. I understand that making a portable assembly language would completely fail on the account of what assembly is made for. What I'm also bring into view is that no programming languages low enough like C/C++ are portable. The only part of assembly that would be nice to have portable, like C/C++, would be the syntax of the code.
@hamsterman Thank you for helping.
(sorry I have been busy and oh my thread finally got going didn't it?)
@hamsterman Thank you for helping.
(sorry I have been busy and oh my thread finally got going didn't it?)
Knowing a lot about assembly and language architecture, I am telling you that you are trying to split oranges and oranges.
Yes, it would be nice to use some form of standard syntax to embed assembly code in C and C++ code, but that is the same as saying it would be nice to have come form of standard assembly syntax, which cannot be done.
Yes, it would be nice to use some form of standard syntax to embed assembly code in C and C++ code, but that is the same as saying it would be nice to have come form of standard assembly syntax, which cannot be done.
@Duoas, could you post an example of an assembly language that cannot be expressed in format
instruction_name arg, arg, arg, ...
where arg is a register_name, constant or memory address of the form [function_of_registers_and_constants]
I'm only familiar with x86, so I don't know any and I don't see when MIPS would be a problem..
instruction_name arg, arg, arg, ...
where arg is a register_name, constant or memory address of the form [function_of_registers_and_constants]
I'm only familiar with x86, so I don't know any and I don't see when MIPS would be a problem..
Last edited on
@Duoas,
I don't agree, I think all they mean is that where in gcc you do this:
or something
In VCC you do something like this:
which makes a lot more sense to me.
I don't agree, I think all they mean is that where in gcc you do this:
asm("mov %%eax, %0" ::"=r"(a));or something
In VCC you do something like this:
|
|
which makes a lot more sense to me.
A simple VLIW instruction (taken from the FreeScale StarCore processor):
All three operations occur in parallel and are part of a single instruction.
Another StarCore instruction with 6 parallel operations (uses brackets to spans multiple lines for readability):
More complex VLIW instructions on other architectures add conditional tests for each operation, so a single instruction can contain operations which are always executed, operations which are executed only if the condition flag is set, and operations which are executed only if the condition flag is cleared.
Many instruction sets (including the IA-32 and IA-64 architectures) support instruction prefixes or qualifiers such as "REP", "LOCK", or "NOIRQ". This would change the instruction format given by hamsterman to
with optional labels and optional prefixes (in addition to zero or more arguments).
Even the format for an arg is going to be hard to nail down. Some architectures have arguments with spaces in them (ARM's "R1, LSL #4" and "R1, ROR R3" arguments), while other architectures need to use spaces to distinguish between arguments are new operations.
asrr #3,d0 tfr d0,d1 move.w #5,d0 All three operations occur in parallel and are part of a single instruction.
Another StarCore instruction with 6 parallel operations (uses brackets to spans multiple lines for readability):
|
|
More complex VLIW instructions on other architectures add conditional tests for each operation, so a single instruction can contain operations which are always executed, operations which are executed only if the condition flag is set, and operations which are executed only if the condition flag is cleared.
Many instruction sets (including the IA-32 and IA-64 architectures) support instruction prefixes or qualifiers such as "REP", "LOCK", or "NOIRQ". This would change the instruction format given by hamsterman to
[label:] [prefix] instruction arg, arg, argwith optional labels and optional prefixes (in addition to zero or more arguments).
Even the format for an arg is going to be hard to nail down. Some architectures have arguments with spaces in them (ARM's "R1, LSL #4" and "R1, ROR R3" arguments), while other architectures need to use spaces to distinguish between arguments are new operations.
closed account (43RGz8AR)
Thank you mpauna! That is something valid to compare to. Although that is the kind of problem that is solved by code prefixes, like what I had before.
You could take that farther for other instruction sets and architectures, but non the less a valid point. Existing assemblers already do this kind of thing for that exact reason.
|
|
You could take that farther for other instruction sets and architectures, but non the less a valid point. Existing assemblers already do this kind of thing for that exact reason.
@Chrisname
I completely agree, but I already responded to that issue above.
http://www.cplusplus.com/forum/lounge/56399/2/#msg305515
Be sure to click the xkcd link for all the related fun.
I completely agree, but I already responded to that issue above.
http://www.cplusplus.com/forum/lounge/56399/2/#msg305515
Be sure to click the xkcd link for all the related fun.
Topic archived. No new replies allowed.
Pages: 12