Index
> Compiler Internals > [bug] fastcall param's byte/word override. |
| Author |
|
|
revolution 16 Mar 2018, 11:10
Or perhaps use movzx.
|
|||
16 Mar 2018, 11:10 |
|
|
fasmnewbie 16 Mar 2018, 11:34
yup.
I think the bug affects the entire parameter set, not just r8,r9. |
|||
|
16 Mar 2018, 11:34 |
|
|
Tomasz Grysztar 16 Mar 2018, 13:27
The assumption was that if you pass an argument with a size of 1 byte, the higher bytes are undefined. Note that the same thing happens on the stack:
Code:
; ...
else if size@param = 2
mov ax,param
mov [rsp+(counter-1)*8],ax
else
mov al,param
mov [rsp+(counter-1)*8],al
end if
; ... |
|||
|
16 Mar 2018, 13:27 |
|
|
fasmnewbie 16 Mar 2018, 17:34
In my opinion, the higher bytes should not be left undefined though. It serves no practical purposes other than giving the users a wrong semantic of what the override byte means. It gives the impression that for example using a "byte" override uses the same quantity as using a qword, which is correct from CPU's POV, but not so from high-level POV, which is what "fastcall" is all about. Besides, byte is a strong semantic keyword though.
For example; Code: section '.data' data readable writeable fmt db '%02x',0ah,0 val dq 1177345566h section '.text' code readable executable main: sub rsp,40 movzx ebx,byte[val] fastcall [printf],fmt,bl call [getchar] mov rcx,0 call [exit] What came out was "402066" for BL but correctly displays "66" when using EBX. Now here the semantic is reversed - the byte register returns larger quantity while a 32-bit register returns a byte. After modifying the "fastcall" macro (via RDX), both gives the correct semantic of a "byte". Just an opinion. |
|||
|
16 Mar 2018, 17:34 |
|
|
Tomasz Grysztar 17 Mar 2018, 13:00
The semantics of a byte-sized parameter to "fastcall" macro is that the argument passed is of a type with such size. It is expected that you use it when calling a function that takes an argument with such type, like when you use the "proc" macro with an argument with ":byte" modifier:
Code: proc tester, p1,p2,p3,p4,p5:byte ; ... mov al,[p5] ; ... endp ; ... fastcall tester,1,2,3,4,byte 5 |
|||
|
17 Mar 2018, 13:00 |
|
|
revolution 17 Mar 2018, 22:11
I think that is too restrictive on usage. There are many API function where passing in bytes from a string is useful but we can't know the underlying code.to confirm that it uses the byte as we require. So when we don't know the nature of the called code we then have to be coding extra instructions to ensure the whole qword is zeroed. It is more work for the poor programer and it doesn't really follow the principal of least surprise.
|
|||
|
17 Mar 2018, 22:11 |
|
|
Tomasz Grysztar 18 Mar 2018, 07:29
If macro was expected to cast the arguments into appropriate type, it would need to have the signature of the function declared. These macros do not need such declaration and are "low level", with the assumption usual to assembly languages, that the programmer knows what exact types of data the called function expects.
|
|||
|
18 Mar 2018, 07:29 |
|
< Last Thread | Next Thread > |
Forum Rules:
|