#13 TASM pseudo instr. adapt.; (E)SP based local variables

[Anonymous]

Adaption of TASM built in code optimizing pseudo instructions
-------------------------------------------------------------

MASKFLAG dest,src - Optimized AND
SETFLAG dest,src - Optimized OR
FLIPFLAG dest,src - Optimized XOR
TESTFLAG dest,src - Optimized TEST

These instructions cause TASM to generate size optimized code whenever it is possible. They are automatically used by TASM whenever it encounters any high level syntax statements (.if/.while ...). This only affects instructions where constants and/or address operators are involved.

Examples:

source -> result:
maskflag eax,0ffff3fffh -> and ah,3fh
setflag ebx,8000h -> or bh,80h
setflag edi,8000h -> or di,8000h
flipflag ecx,0f0h -> xor cl,0f0h
testflag edx,0f000h -> test dh,0f0h

maskflag my_dword,not 4000000h -> and byte ptr my_dword+3,not 4
setflag my_dword,0f00000h -> or byte ptr my_dword+2,0f0h
flipflag my_dword,0ff000h -> xor word ptr my_dword+1,0ff0h
testflag my_dword,0ff00h -> test byte ptr my_dword+1,0ffh

(E)SP based local variables instead of (E)BP based ones
-------------------------------------------------------

To make the (E)BP register available for programming instead wasting it as a pointer to the local procedure variable storage/argument stack the (E)SP should be tracked and the offsets to stack variables should be calculated dynamically, like some C compilers do.
In 16 bit this would need some workaround for the programmer because SP isn't directly accessible here, but I wouldn't see a big problem with it.

[Nobody/Anonymous]

> Adaption of TASM built in code optimizing pseudo instructions

I see very little additional value supporting these pseudo instructions.

> (E)SP based local variables instead of (E)BP based ones

Yes, I also considered this feature. But tracking changes of ESP is pretty impossible.for the assembler, as you can easily see in the following code snippet:

mov ecx, 5
xor eax, eax
@@:
push eax
loop @B

So probably the only appropriate and clean solution is NOT trying to track changes of ESP. This approach leaves the burden to the programmer, which then has to assist the assembler in calculating the correct values for ESP - perhaps by introducing new pseudo instructions, somewhat similar to "ASSUME"?

The question here is the same as with the first proposal: is it really worth the trouble?

japheth

[Nobody/Anonymous]

xxxFLAG pseudo instructions:
According to "AMD Athlon Processor x86 Code Optimization Guide" 22007.pdf, page 54:

"Assemblers and compilers should generate the shortest instruction encodings possible to optimize use of I-cache and increase average decode rate"

I think that could be a reason to implement such a feature. Because of such I like using TASM currently, despite of its age.

(E)SP based local variables:
OK, I must admit that this feature is very hard to implement because each stack relevant instruction needs to be supervised by the assembler itself.

You mentioned a looped PUSH instruction. That's true, it can't be traced, especially if the loop has a variable count. Such constructs must be exceptable from the tracing process, e.g.:

mov ecx,5
.repeat
OPTION STACKTRACE:OFF
push eax
OPTION STACKTRACE:ON
.untilcxz

or something.

I've been deliberating about a similar problem: developing macros for easier handling of the FPU register stack.
Therefore I am able to assess which problems such a feature may cause.
But I don't want you to overcharge with the solution of this problem.

Regards, Martin.

[japheth]

> code optimizing pseudo instructions

IMO that's quite some effort and little to gain

> (E)SP based local variables instead of (E)BP based ones

An OPTION FPO is in the pipeline - with low priority. However, if it is realized some day, it will be without ESP tracking - this responsibility will be up to the programmer.