The MASM Forum

Projects => Rarely Used Projects => GoAsm => Topic started by: shankle on September 10, 2014, 08:40:26 PM

Title: compiler suggestion
Post by: shankle on September 10, 2014, 08:40:26 PM
The following would help guys like me that are struggling to convert
their programs to GoAsm:

        Ptmem   dq  0     ; pointer

        Then  for whatever reason I make the following error:
          mov ebx,[Ptrmem]
        The compiler does not catch this and for me it would be so nice
        if it did. Most of my errors are caused by this situation.
       Thanks for GoAsm.....
Title: Re: compiler suggestion
Post by: rsala on September 11, 2014, 04:54:40 AM
Ptmem is a 64-bit variable and you are trying to load its value in a 32-bit register. Try this:

mov ebx, D[Ptrmem]

Title: Re: compiler suggestion
Post by: shankle on September 11, 2014, 06:04:02 AM
Thank you for responding.
BUT you miss interpreted my message.
I know that rbx should be used with a DQ Ptrmem.
But in the conversion process to many changes have to be made
and I have a bad habit of missing this one.
If the compiler caught it I would have less trouble.
Title: Re: compiler suggestion
Post by: Yuri on September 11, 2014, 01:08:25 PM
Sometimes it's convenient to read a part of a variable.
Maybe it could be a warning rather than an error, and one that you would explicitly turn on by some flag in the command line if you needed it.

But I suspect implementing such type checking will be quite a job. See what Jeremy wrote in the help file on this:
Why GoAsm does not type or parameter check

After some thought I decided that GoAsm ought not to type or parameter check. This, I believe, reduces the size of the source script enormously, and adds to its flexibility and readability. I have concluded that even basic type checking in assembler programming for Windows is not at all essential, and is more trouble than it is worth.
Let me explain.
In type checking the Assembler must check that references to areas of memory are made with the correct size and type of data to suit what the area of memory is intended to be used for. This is achieved through a two-stage process. Firstly when the area of memory is declared the programmer must allocate it a certain "type". Then when the area of memory is used, the programmer has again to state the type of memory intended to be used. If there is a mismatch the assembler or compiler will show an error.

Some assemblers, like NASM, do no type checking at all. Others, like A386, do only basic type checking based on the byte, word, dword, qword and tword types. MASM and TASM, like "C", allow you to specify your own types using TYPEDEF and then type-check based on those specified types.
Parameter checking checks that the correct number of parameters are passed to an API and also type checks the parameters. Most assemblers do not parameter check but MASM permits parameter checking when the INVOKE pseudo mnemonic is used.
The overheads required to achieve full type and parameter checking like a "C" compiler are enormous. Just look through a Windows header file and see the long lists of various types allocated to various structures and to the parameters of APIs. Then look at the efforts of the programmer which are required in the source script to ensure that no error is thrown up by the assembler or compiler.

I decided to follow the NASM example and not even offer basic type checking as A386 provides. I have used A386 over many years and have enjoyed its clean syntax, but I have only found its basic type checking a hindrance when programming for Windows. This is because there are often occasions when you want to write to data, or read from data using a different size of data than used to declare the data in the first place.

As for parameter checking, again I have not even tried to offer this since in my view it unnecessarily complicates things. It again requires enormous lists of APIs and parameters to be provided to the assembler or compiler so that it can check that these match what you are giving the API. Miss one and your program does not compile.

Title: Re: compiler suggestion
Post by: rsala on September 11, 2014, 11:07:21 PM
Hi shankle,

Sorry! Yes, I miss interpreted your message.
Title: Re: compiler suggestion
Post by: shankle on September 12, 2014, 12:07:09 AM
Thank you Yuri,
Guess I will have to be a lot more careful. I now see why it is not done.
So I consider this thread closed.