Request for assistance on a new BETA version of MASM32.

[hutch--]

qWord,

I have been playing with the idea of prefixes as you designed the macro that uses them, I thought it would be a good idea to add the indirection operator as well so that you have both REFERENCE and DEREFERENCE as prefix operators.

I have a working test piece that is doing this OK on the generic macros for MASM32,

Code Select Expand


  ; -------------
  ; expand prefix
  ; -------------
    expand_prefix MACRO txtitm
      LOCAL prefix1,wrd,nu,varname

      prefix1 SUBSTR <txtitm>,1,1

   ;; usable characters are "&" "*" "@" "#" "?" "^" "~" "`" "/"

        IFIDN prefix1,<&>                   ;; reference operator
          nu SUBSTR <txtitm>,2
          wrd CATSTR <ADDR >,nu
          EXITM <wrd>
        ENDIF

        IFIDN prefix1,<*>                   ;; indirection operator
          nu SUBSTR <txtitm>,2

          IF op_type(nu) eq 5               ;; if its a register
            mov nu, [nu]
            EXITM <nu>
          ELSE
            .data?
              varname dd ?
            .code
            push ebx
            mov ebx, nu
            mov ebx, [ebx]                  ;; dereference variable in EBX
            mov varname, ebx
            pop ebx
            EXITM <varname>
          ENDIF

        ENDIF

      EXITM <txtitm>                        ;; exit with original argument
    ENDM


Notation example is as follows.

Code Select Expand


fn MessageBox,0,*parr,&titletxt,MB_OK


Now another comment, the macros that were in WINDOWS.INC should not have been there, specifically the ones that specify ASCII or UNICODE. I remember that you had written your own and this would be useful in supporting your new macro system where you use prefixes to force either ASCII or UNICODE if desired. There is a limited range of single characters available to use as prefixes but it is worth avoiding single alphabetic characters for clarity reasons, it makes sense to use the "?" character as the UNICODE prefix as it mirrors what UNICODE displays in ASCII. For the reverse when forcing ASCII, an ordinary macro would do the job.

Code Select Expand


    ascii MACRO quoted_text
      LOCAL txtname
      .data
        txtname db quoted_text,0
      .code
      EXITM <OFFSET txtname>
    ENDM


Let me know what you think.

[ToutEnMasm]

Good idea to add a set of macros to simplify pointers usage.
Perhaps this ones can be of some use.
http://www.masm32.com/board/index.php?topic=17351.msg145740#msg145740
They replace the assume directive and act as c++ with the pointed data.
start idea is simple.

DECLARE_pointer TEXTEQU <MyStruct>

and the macros do what is needed to move and adress data.
here a sample of use
http://www.masm32.com/board/index.php?topic=17108.msg145682#msg145682

Another sample is this macro

;add: DECLARE_pointeur TEXTEQU <STInterFace>
;where pointeur is
; pointeur dd     ;all name who get the com pointer
; USAGE:
; COM pointeur,Release  ;usefull with duplicate pointer
COM MACRO ppv:REQ,fonction:REQ,args:VARARG
   local InvokeInterface
   computeoffset CATSTR <DECLARE_>,<ppv>
   ;---------- controle les arguments
    FOR arg, <args>     ;verifier que edx n'est pas dans la liste d'arguments args
        IFIDNI <&arg>, <edx>   ;
            .ERR <edx is not allowed as a coinvoke parameter>
        ENDIF
    ENDM
    IFIDNI <&pInterface>, <edx>
        .ERR <edx is not allowed as a coinvoke parameter>
    ENDIF
   ;------------ --------------------------------
   ;InvokeInterface = concatene ...CATSTR(concatene) MACRO instruction MASM32   
   ;---------------------------------------------
    InvokeInterface CATSTR <invoke (computeoffset ptr  [edx]).>,<&fonction,ppv>
    IFNB <args>     ; add the list of parameter arguments if any
        InvokeInterface CATSTR InvokeInterface, <, >, <&args>
    ENDIF
   ; -----------------------
    mov edx, ppv
    mov edx, [edx]
    InvokeInterface      
ENDM

[qWord]

hutch,

do you think it make really sense to use the fnx/rvx macros, whereas these new features could be simply added to the existing fn[c]/rv[c] macros?  IMO this would make the macro interface more uniform.
Adding support for the L-prefix, referencing and dereferencing wouldn't break existing code - regardless this, we could include an equate like 'MASM32_V10_COMPATIBLE', which force the old macro definition.
To your previous post: Did I understand you right: you want to use '?' as a unicode prefix? In context to your nice idea of the c/c++  dereferencing-operator (and it counterpart '&'), it would break the macro's syntax consistency (IMO).

To the implementation of the dereferencing-operator:  I would use the stack instead of a global variable because it is thread save and probably faster (the stack is cached). Also overwriting any registers is not a good attitude  :bg
Here an example how I would solve  'dereferencing':

Code Select Expand

; nParam = number of  function arguments
; iParam = current argument index (zero-based)
; txtitm = argumetn to check
expand_prefix MACRO nParam,iParam,txtitm

  expprfx_prefix SUBSTR <txtitm>,1,1

    IFIDN expprfx_prefix,<&>                         ;; reference operator
      expprfx_arg SUBSTR <txtitm>,2
    %  EXITM <ADDR &expprfx_arg>
    ENDIF

    IFIDN expprfx_prefix,<*>                         ;; indirection operator
      expprfx_arg SUBSTR <txtitm>,2
      IF op_type(%expprfx_arg) eq 5                  ;; if its a register
        mov expprfx_arg, [expprfx_arg]
    %    EXITM <DWORD ptr [&expprfx_arg]>
      ELSE
        mov eax,expprfx_arg
        mov eax,[eax]
        mov DWORD ptr [esp-2*nParam*4+iParam*4],eax  ;; store argument on stack
EXITM <DWORD ptr [esp-nParam*4-4]>           ;; return esp-relativ argument for INVOKE-directive
      ENDIF
    ENDIF
  EXITM <txtitm>                                     ;; exit with original argument
ENDM

    fn MACRO FuncName:REQ,args:VARARG
      p@args equ <invoke FuncName>        ;; construct invoke and function name
      n@args = argcount(args)             ;; get number of arguments
      i@args = 0
      FOR var,<args>                      ;; loop through all arguments
        p@arg TEXTEQU reparg(var)         ;; replace quotes
        p@arg TEXTEQU expand_prefix(%n@args,%i@args,%p@arg) ;; replace special operators
        p@args CATSTR p@args,<,>,p@arg    ;; p@args + <,> + p@arg
      i@args = i@args + 1               ;; update argument index
      ENDM
      p@args                              ;; write the invoke macro
    ENDM

[hutch--]

The "rv", "fn, "rvc" and "fnc" macros have all been rewritten to handle both ASCII and UNICODE and are working in a reliable manner and they must stay independent as they are used by a large number of other macros. I wanted to keep your "rvx" and "fnx" as separate extended versions so that the programmer has the choice of which version they use but I would like to see a C escape version of both as well which is easy enough to do. One other thing, the C escapes should support "\0" as well for embedded nulls in string like those that are used for common dialogs for file types and extensions. "All Files\0*.*\0\0".

You are right about overwriting the register and I had already removed it, I will have a look at the stack technique you have used but I have no problem using a macro LOCAL variable that ends up in the data section as each is unique and therefore thread safe.

[hutch--]

Now just a quick look at the macro and you are overwriting EAX which can cause problems wit following arguments that are returned in EAX. I did not want any of the compound macros to overwrite any register, that is why I used the unique data section variable.

[qWord]

I wanted to keep your "rvx" and "fnx" as separate extended versions so that the programmer has the choice of which version they use but I would like to see a C escape version of both as well which is easy enough to do. One other thing, the C escapes should support "\0" as well for embedded nulls in string like those that are used for common dialogs for file types and extensions. "All Files\0*.*\0\0".

OK - I will send you the new macros fnx[c]/rvx[c] the next days, which will have following features:
- L-prefix for Unicode strings (should work, because you have removed the L-macros from windows.inc)
- string creation according to __UNICODE__-equate
- A-prefix to force ASCII strings, even if __UNICODE__ is defined
- reference &
- dereference *
- optional, additional assignment using =
Also I will update the UCCSTR -macros to support \0.

Now just a quick look at the macro and you are overwriting EAX which can cause problems wit following arguments that are returned in EAX. I did not want any of the compound macros to overwrite any register, that is why I used the unique data section variable.

no problem: eax can also saved on the stack: mov DWORD ptr [esp-4],eax ... mov eax,DWORD ptr [esp-4]  :bg

[hutch--]

qWord,

For the C escape versions, name them "rvcx" and "fncx" so they are consistent with the existing names. What I want to be able to provide is the generic versions and the extended versions as two separate systems so the user can select which method they want to use with either being dependent on the other. I need these for the next BETA as I have already done most of the documentation for the new extended system and I will need to change that before the next BETA.

[qWord]

hi,
In the attachment the new macros and updated examples.

What has changed (this may be importend for the documentation):

- the fncx and rvcx macros were added
- \0 - escape sequence added  (UCCSTR/ucc$, rvcx/fncx)
- the Unicode prefix has been change from u to L  (rv[c]x/fn[c]x. The L()-macro, which was placed in Windows.inc must be deleted)
- A-prefix added to force ASCII strings (rv[c]x/fn[c]x)
- *-operator added to rv[c]x/fn[c]x , thread safe , only pointers to DWORDs can be dereferenced
- a new macro for internal purpose is added: ?cstr? -> ASCII c-strings, syntax-compatible to UCCSTR
- the repargs-macro has a new, additional argument, which allows to enable support for c-strings. Also this macro has been modified according to the changes in the macros rv[c]x and fn[c]x
- some small changes to the examples

You should replace all macros I've supplied.

regards, qWord

[hutch--]

Excellent, I will unzip it, replace the earlier ones in macros.asm and perform the changes to the documentation.