[ Post removed by author. ]

Check out the Sphinx C-- project.

Also check Octavio's Octasm because it has a syntax close to this what you seek.

However rewriting C code in ASM is not a good idea.

Instead, if you have an algorithm written in C, do try to understand the algorithm in C first and in concepts later on and then rethink and re-implement it in ASM while maintaining an ASM kind of HLL structure by using multiple .if .elseif .else .endif, using invoke/stdcall extensively and PROC and ARG and LOCAL.

Many times HLL code writers destroy an algorithm or miss algorithms completely because they do not "think in ASM concepts"

I have seen that there is a big temptation to copy paste algorithms and programs from the existing C or HLL base just to get "a head".

However this is a bad idea because you skip the (arguably slow) process of learning and understanding just to get something working "faster"

And this kind of attitude will back fire later on.

[ Post removed by author. ]

mikegonta,

For simple instructions like add eax, ebx notation is obvious, but what about more complex one (CISC, heh? ), xchg eax, ebx for example? Or MMX/SSE#/whatever…

By the way, eax = BYTE *ptr; and movzx eax, BYTE [ptr] aren't equivalent, are they? May be eax = *(unsigned BYTE *)&ptr;?

[ Post removed by author. ]

[ Post removed by author. ]

The ADC looks very problematic. One needs to be careful about opcode reordering due to optimisation steps. Remember that x86 has a fixed assignment of which opcodes update the flags, so the carry can easily become overwritten by intervening instructions.

[ Post removed by author. ]

Oh! It is not immediately clear where the carry is from this code you posted above: One has to see the ASM before it becomes clear where the carry is generated.

But what about: If all operators have equal precedence then how is it going to be evaluated? L-to-R?

mikegonta,

OK, let's make it straight: ptr in your example is constant or variable? void * const ptr = 0xB8000; or void *ptr; (not strictly correct, but enough to catch the difference)?

Terse appears to be too terse , it reminds me APL on ASCII diet. Assembly programming is complex enough to make it unnecessary cryptic. Do you remember C operators' precedence? What about

I think, verbosity of pure assembly is a merit, not flaw. You can use macros to automate repetitive tasks, for example to define new instruction
mov sreg2, sreg1 having opcode 000sr110 000sr111 with side-effect of setting [sp-2]

revolution,

I thought Mike was about new syntax for instructions, not granting compiler right to evaluate run-time expressions…

Okay we need Mike to clarify that. But this code (posted by Mike) seem to show complex expression evaluation:

[ Post removed by author. ]

[ Post removed by author. ]

[ Post removed by author. ]

Now that is just scary and crying out for ease of making subtle and hard to find bugs.

[ Post removed by author. ]

mikegonta,

OK, compound assignment (op=) should be banned as counter-intuitive (consider eax –= ebx – ecx; ). What about beloved mul r/m?
edx:eax = eax * r/m32?

I'm not nit-picking. To describe most of useful instructions it will take several lines (if not pages) of C-like pseudocode. New syntax only for a few instructions? Does it worth efforts?

[ Post removed by author. ]

mikegonta,

"Merely notation shortcut"? In C
expr1 += expr2 is semantically different from
expr1 = expr1 + expr2

eax -= ebx - ecx compiled as eax -= (ebx + ecx) will be unpleasant surprise for almost any C programmer.

Can rcl qualify as simple instruction?

Why don't use postfix notation? It's unambiguous and you'll end up with another FORTH compiler…

Jokes aside, may be you should try to write specification for that syntax (just syntax, i.e. rules for statement composition, for a small subset of instructions of your choice)? It's not easy to develop consistent yet simple to use syntax.