OPTION STACKBASE fails in x86

[aw27]

I am sure you did not even notice that stackbase:rsp makes the code bigger and slower.

You are judging hard-working people here - that is not helpful.

It is not helpful to state that stackbase:rsp makes the code smaller and faster. It does not.

[hutch--]

aw27,

There is not a point to win here. You are obviously experienced in writing assembler and this is very useful to folks who creating the tool in the first place but as I am sure you can imagine, the guts of an assembler is a nightmare to work on and both authors inherited some of this mess in JWASM that had a number of experimental techniques that have proven to be problematic.

Keep in mind that JWASM was supposed to have been MASM compatible yet in its experimental stage it added a range of un-necessary experimental code that was clearly NOT MASM compatible so the pursuit of some clean up and simplification is in fact a good idea. The MACRO capacity of writing your own prologue and epilogue is probably a far better method of producing custom stack usage and procedure calls than a plethora of unreliable experiments. This means the assembler can be cleaned up to produce predictable and reliable code and the brave/foolish/experimental or dedicated can cook their own if they can get it going. This keeps everybody happy.

Constantly hassling people doing complex work is counter productive and it can lead to them thinking "PHUKIT" and do something else for a while.

[aw27]

aw27,
This keeps everybody happy.

I am not against tools for dumb people, my first Assembler was TASM in Ideal mode (sighs...).
May be we can make an Ideal mode for HJWASM ?!

[jj2007]

May be we can make an Ideal mode for HJWASM ?!

The Ideal Mode is the one that allows you to port your sources from Masm32 (ML 32, ...) easily, without having to experiment with cryptic options. In phase II, you can pick the routines that you think can be made faster, and start playing with the options.

There is a huge Masm32 codebase. IMHO it would be unwise to tell its authors "we have a better assembler now, all you have to do is to read a 50-page manual".

[nidud]

deleted

[johnsa]

Hi,

Thanks for the pointers!
I think given you've supplied working fixes for stackbase:esp , and after some soul searching on the wknd I believe we should put it back in :)
There are definitely cases for optimisation where you'd want it.

With regards to your last point on calling convention I assume you meant fastcall for 32bit not 64bit ?

Habran and I are busy looking at building completely new versions of invoke and proc.c .. to be honest it's gotten very messy and there's just too much going on in the same functions trying to cater for every mode.
We want to refactor it all out into dedicated calls for:

SystemV ABI
Win64 Fastcall(RSP)
Win64 Fastcall(RBP)
Win64 VectorCall( using RSP )

We'd keep the existing code in place to handle all the 32bit options.

[nidud]

deleted

[johnsa]

I tend to agree, I would like them all completely separated from language descriptor/type right through the actual source.
One of the biggest issues we've faced is you make a chance to proc or invoke and it's not side-effect free, a change to win64 fastcall can break vectorcall etc etc.. and that scares me long term, it would be so much more maintainable if separated (and also refactored) to account for removing all the needless / experimental options.

[hutch--]

john,

There is an approach that should solve that problem, the OPTION CASEMAP style of directive put before and after a procedure could safely control differences between ABI style proc entry and exit and any custom designs you wanted to make available.

OPTION DO_IT_IN_AVX3

    ; write the code here

OPTION DEFAULT

This would allow you to have a sequence of options for procedure types with potentially different calling conventions.

OPTION SAFE
OPTION NONE
OPTION RSPCALL
OPTION RBPCALL
etc .....

This would allow you to modularise it and then you could safely add anything else you want to provide later.

[johnsa]

Definitely in line with what I was thinking.
Over the weekend I'd tentatively started rolling up stackbase/frame:auto etc into a standard combination.. but decided to scrap it as it just had a "bad code smell" :)
I'm leaning more towards leaving those as is for now, and rather.. as you've suggested creating new options for each "mode" which may or may not imply the other settings automatically.

So for example

OPTION WIN64_FASTCALL_RSP
= (frame:auto, win64:11, stackbase:rsp, all procs are auto-decorated with FRAME) [local align 16 guaranteed, smart save to home-space, stack use optimized]

OPTION WIN64_FASTCALL_RBP
= (frame:auto, win64:11, stackbase:rbp, all procs are auto-decorated with FRAME) [local align 16 guaranteed, smart save to home-space, stack use optimized]

OPTION SYSTEM_V
= (64bit Nix* ABI)

OPTION VECTORCALL

etc

[aw27]

Definitely in line with what I was thinking.
Over the weekend I'd tentatively started rolling up stackbase/frame:auto etc into a standard combination.. but decided to scrap it as it just had a "bad code smell" :)
I'm leaning more towards leaving those as is for now, and rather.. as you've suggested creating new options for each "mode" which may or may not imply the other settings automatically.

So for example

OPTION WIN64_FASTCALL_RSP
= (frame:auto, win64:11, stackbase:rsp, all procs are auto-decorated with FRAME) [local align 16 guaranteed, smart save to home-space, stack use optimized]

OPTION WIN64_FASTCALL_RBP
= (frame:auto, win64:11, stackbase:rbp, all procs are auto-decorated with FRAME) [local align 16 guaranteed, smart save to home-space, stack use optimized]

OPTION SYSTEM_V
= (64bit Nix* ABI)

OPTION VECTORCALL

etc

Another possibility, allow the user to fabricate his own calling convention (which could be entered with the name CUSTOM either in the PROTO or PROC declarations).
incidentally, IDA Pro can deal with custom calling conventions.

[jj2007]

And don't forget the PROLOG and EPILOG macros. Especially the last argument, userparms, is a very flexible tool. Not for n00bs, though.

[aw27]

And don't forget the PROLOG and EPILOG macros. Especially the last argument, userparms, is a very flexible tool. Not for n00bs, though.

Looking more for a "super" INVOKE able to deal with CUSTOM calling conventions. For example, I deal frequently with the Borland Register calling convention and have to do all the work by hand which is a bit tiring and error prone.

[jj2007]

Looking more for a "super" INVOKE able to deal with CUSTOM calling conventions.

Maybe you can get inspiration from line 829ff in \Masm32\MasmBasic\Res\JBasic.inc

Code: [Select]

jinvoke MACRO apiarg, args:VARARG
It's only about 350 lines to study :P

[johnsa]

One of the changes we've made to 2.22+ is that we now have a built-in macro library, it's small now.. just a few to test the idea out, but over time we can extend it.. the hope being that there are some assembler features which are actually smarter to implement as macros rather than modifying the raw code of hjwasm.. this could be an example of that.. where we can create a custom invoke macro, but it's built-in.. so you wouldn't notice the difference! (it relies on existing working logic as opposed to fiddling with core stuff that might introduce new regressions).

So if we have some solid generic macros between us all that we'd like to see built in.. :) you know where to send them!