Multiple Assembly Language Syntax Support

[MrTimmyToes]

I've noticed that as an assembly programmer, there are for the most part, two types of syntax's.  Switching from one to the other can get confusing to the coder.  For some assemblers, the AT&T syntax is used while other's are Intel syntax.

What if there were a preprocessor directive such as #SYNTAX to define which style of coding is being used?
Example:
#syntax intel
 mov eax, [ebx] // Load the contents from memory location ebx to eax.

or...

#syntax att // at&t
mov eax, [ebx] // Store eax to memory location pointed by ebx.

This would make it easier for those accustomed to one syntax over another.

I'm curious about your thoughts on this, Pelle.

Tim

[Pelle]

Not sure. Possibly useful if you want to compile the same C code, with embedded inline assembly, on different compilers. I doubt it's enough to just switch the argument order - there are usually other syntax differences and "environment issues" to deal with.

If it's more a matter of converting from AT&T style once: I have seen some tools on the Internet that are supposed to do that. Not sure if they actually work - and are still around...

Pelle

[MrTimmyToes]

Pelle,

I can see where you are coming from.  I do understand how data is manipulated between assemblers.  That is, for example, two assemblers could use the same intel syntax but the instruction "mov eax, SomeVar" is different in MASM than it is in another assembler.  One assembler may think that we want to load the address of SomeVar into eax while others want to load the contents of SomeVar into eax.

I'm not saying changing the way Pelles C compiles code, but rather just allow the programmer to choose which operand order to use.  So there may still be modifications porting code from one assembler to Pelles C, but at least the programmer can choose which operand order to use.

opcode dest, src
OR
opcode src, dest

So we keep the same assembly style that Pelles C is using, only we allow a different order of writing the same piece of code.

Hence, the following would be equal in Pelles C.

#syntax intel
mov eax, ebx

#syntax att
mov ebx, eax

Perhaps my Subject title really should be "Multiple Operand Oder."

Tim

[Pelle]

I'm not saying changing the way Pelles C compiles code, but rather just allow the programmer to choose which operand order to use.

OK - I understand. I guess I didn't read your first post well enough.

I will not do anything in v4.0, especially since I'm working on a new backend assembler, but I will try something in the following release.

Or may be and add-in could do the job ?

Yes, this could be useful. It just has to be written... ;-)

Pelle

[Vortex]

Hi Pelle,

You mentioned that you are working on a new backend assembler. What will be the features of your new tool?

[Pelle]

Hello Vortex,

You mentioned that you are working on a new backend assembler. What will be the features of your new tool?

The most important thing is to replace the current compiler assembler, for inline assembly and code generation, to make it more flexible and easier to add new processors. The current one is stretched to it's limit just supporting two processor families (32-bit X86 and ARM). At some point I need to add X86-64, and maybe other processor types, but I need a more flexible assembler for this...

I will probably also add a frontend, to make it standalone, but this is more uncertain...

Pelle

[MrTimmyToes]

Pelle,

What other processors were you considering supporting and for what systems?

Tim

[Pelle]

What other processors were you considering supporting and for what systems?

MIPS and SH3 for Pocket PC - but I doubt it's worth the trouble.

Pelle

[MrTimmyToes]

Actually, providing Pelles C for Pocket PC seems like an excellent idea.  I'd be more apt to buy a Pocket PC knowing I could easily use the same compiler to do routines on PC and PocketPC rather than installing a completely new compiler.

Is the issue implementing that involve a lot of work on your end?

What date are you hoping to release Pelles C 4.0? March 2006?

[Pelle]

Is the issue implementing that involve a lot of work on your end?

Yes. The compiler must emit (correct) instructions for the new machine, the assembler must handle the new machine instructions, the linker must handle new relocations for that machine, the binary dump utility "needs" a new disassembler (for my tests, at least), and so on...

I think it was for Pocket PC 2002 that Microsoft said the ARM processor was the "preferred" one - no more support for MIPS and SH3. Not sure if this is still the case. Adding MIPS and SH3 support might just be for older processors (that will eventually disappear...)

What date are you hoping to release Pelles C 4.0? March 2006?

Hopefully a lot sooner... ;-)
It depends on the bug reports. Nothing reported for a while - if this continues, I will release it soon...

Pelle