Would someone like to share how to get ATOFLt to work in masm (uasm)? I'm having no luck at all.
include \masm32\MasmBasic\MasmBasic.inc
SetGlobals MyFloat:float
Init
Dll "ucrtbased"
Declare void _atoflt, C:3
_atoflt(addr MyFloat, Chr$("12345.67890"), 0)
Inkey Str$("The result is %9f", MyFloat)
EndOfCode
Output: The result is 12345.6787
You can use ucrtbase (without the "d"), too. If you don't have MasmBasic (http://masm32.com/board/index.php?topic=94.0) installed, LoadLibrary and GetProcAddress are your friends.
So how does that work for a non-MasmBasic user, JJ?
Quote from: NoCforMe on February 28, 2024, 12:28:40 PMSo how does that work for a non-MasmBasic user, JJ?
As written above, LoadLibrary and GetProcAddress are your friends. Go ahead, don't be lazy,
code it. I am sure you are able to do it, now that I gave you all the necessary info.
Look, Bub, I'm a little tired of you accusing me of being "lazy".
Look: This is the Campus. Where presumably users who don't have all that much experience with assembly language ask questions.
The OP specifically asked about MASM or uasm, not MasmBasic.
LoadLibrary() and GetProcAddress()? OK, fine: just what library (DLL) can that function be found in? You didn't give that anywhere.
Why don't you just answer the damn question simply so the asker can actually use your information?
Quote from: NoCforMe on February 28, 2024, 12:53:59 PMso the asker can actually use your information
Since Jim is one of the most experienced users here, I am sure he will briefly look at my code and say "Oh, that's it, so simple!".
Anyway, you seem to always have time to criticise others, why don't you sit down and code the campus style example in "pure" Masm32? It won't take you more than 10 minutes.
Would you care to at least tell me where I can find this function? What DLL?
ucrtbase.dll comes in ucrt packages and Windows 10 have it by default.
Well, I'm really rusty at this bit.
I spent several hours trying to get this to work with no luck.
I stripped most of the crud from my test for you guys to look at.
I'm sure it's something simple I'm just can't see, so if someone would take a look, I'd appreciate it.
.686p
.model flat, stdcall
.nolist
include windows.inc
inv equ invoke
; some miscellaneous macros
soff Macro QuotedText:Vararg ; returns offset to a string
Local LocalText
.data
LocalText db QuotedText,0
.code
EXITM <offset LocalText>
Endm
msgx Macro qtext:VARARG
pusha
inv MessageBox,0,soff(qtext),0,0
popa
endm
uselib MACRO libname
include libname.inc
includelib libname.lib
ENDM
uselibs macro libs:vararg
for nlib,<libs>
include nlib.inc
includelib nlib.lib
endm
endm
uselibs user32,kernel32,comctl32,msvcrt
.listall
.data?
hWin dd ?
buff db 100 dup (?)
buff2 db 100 dup (?)
sfloat dd ?
atoflt dd ?
.data
xfloat dq 123.45677
.code
Program:
inv LoadLibrary,soff("ucrtbase.dll")
.if eax==0
msgx "loadlibrary ng"
jmp wrap
.endif
inv GetProcAddress,eax,soff("_atoflt")
.if eax==0
msgx "GetProcAddress ng"
jmp wrap
.endif
mov atoflt,eax
push 123 ; for testing to make sure I did the stack right
push offset sfloat
push soff("12345.67")
call atoflt
.if eax
msgx "error from atoflt"
jmp wrap
.endif
pop eax ; c call so clear stack
pop eax
pop eax
.if eax != 123
msgx "stack prob"
jmp wrap
.endif
inv crt_sprintf,addr buff2,soff("results= %f"),sfloat
inv MessageBox,0,addr buff2,0,0
wrap:
inv ExitProcess, eax
end Program
Quote from: jimg on February 29, 2024, 03:32:46 AMI'm sure it's something simple I'm just can't see, so if someone would take a look, I'd appreciate it.
If JJ's sample works, the float address argument is supposed to be first. Since in C the arguments are pushed from right to left, the float address should be pushed as last one, just before the call.
You may also want to have a peek at the FpuAtoFL function which is part of the fpu.lib available within the MASM32 package. The source codes of all the functions within the FPULIB are also available for reference if you ever want to write your own functions from scratch (to avoid some of the overhead and/or modify the output for whatever reason).
However, I don't know if 32-bit code can still function on 64-bit systems.
Quote from: raymond on February 29, 2024, 04:30:52 AMI don't know if 32-bit code can still function on 64-bit systems.
16-bit is gone but 32-bit code works fine on 64-bit systems.
@Jim: Japheth is correct.
Yes, I tried that and variations many times. Still doesn't work. Something subtle still wrong.
Thank you raymond. I should have remembered that. Haven't coded asm in about 4 years with a lots of medical problems in between. Brain still a little foggy.
Hi jimg,
It's not recommended to link directly to the import library ucrtbase.lib. You would rather prefer ucrt.lib :
How to correctly link to UCRT (and why it works that way) :
https://mingwpy.github.io/ucrt.html
QuoteCorrectly linking to the UCRT via "API sets" does not require any new features in the toolchain; it's just some clever usage of old, well-supported features.
The only "secret sauce" contained in the ucrt.lib file is the list of (DLL name, symbol name) pairs; given these, we can straightforwardly construct a new .lib file from scratch, and then any binaries that we link using our new .lib file will be linked to the UCRT in a safe, forwards-compatible manner.
https://masm32.com/board/index.php?topic=11525.0
Here is a quick example :
include \masm32\include\masm32rt.inc
_atoflt PROTO C :DWORD,:DWORD
.data
format db 'The result is %f',0
str1 db '3.141592',0
.data?
pi real4 ?
result real8 ?
.code
start:
invoke _atoflt,ADDR pi,ADDR str1
fld pi
fstp QWORD PTR result
invoke crt_printf,ADDR format,result
invoke ExitProcess,0
END start
Nidud's stdlib.inc defining some structures :
_CRT_DOUBLE struct
x real8 ?
_CRT_DOUBLE ends
_CRT_FLOAT struct
f real4 ?
_CRT_FLOAT ends
_LONGDOUBLE struct
x real10 ?
_LONGDOUBLE ends
https://github.com/nidud/asmc/blob/master/include/stdlib.inc
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/atodbl-atodbl-l-atoldbl-atoldbl-l-atoflt-atoflt-l?view=msvc-170
int _atodbl( _CRT_DOUBLE * value, char * str );
int _atodbl_l ( _CRT_DOUBLE * value, char * str, _locale_t locale );
int _atoldbl( _LDOUBLE * value, char * str );
int _atoldbl_l ( _LDOUBLE * value, char * str, _locale_t locale );
int _atoflt( _CRT_FLOAT * value, const char * str );
int _atoflt_l( _CRT_FLOAT * value, const char * str, _locale_t locale );
Thank you.
I got
atoflt3.obj : error LNK2001: unresolved external symbol __atoflt
so something amiss with the whole system on this computer (my wife's laptop, we're on vacation right now).
Will run down the problem, or worse case wait 'till I get home.
Probably why I couldn't get any of the other attempts to work also.
Thank you Erol, your file totally works if built from a command prompt.
My machine is still screwed up, so I still get the error when building from my normal environment.
I'll keep working on it :)
Just to perpetuate this farce, it works if I remember to include-
includelib \masm32\lib\ucrt.lib
DUH!
And the real solution to my original problem is here (https://masm32.com/board/index.php?topic=8449.0)
Yes, again I forgot sprintf format %f wants a double. All this time wasted on a triviality. It was just my checkprint in error, not the actual return value. Duh again. Hopefully someone sometime will be able to get some good out of this mess.
Quote from: jimg on February 29, 2024, 09:34:50 AMI forgot sprintf format %f wants a double
There is _atodbl, same parameters. Or use fld MyFloat & fstp MyDouble.
Yes indeed.
For anyone hanging around this long to find a solution, here is my final test program.
I did it three ways, once with atofl, once with the fpulib, and once with the fpulib but straight to a double.
After all that, I'm going with the fpulib. In my original case, I needed a single, so I'll use that.
Thanks to everyone that contributed and had great patience with my fumbling.
.686p
.model flat, stdcall
.nolist
include windows.inc
inv equ invoke
; some miscellaneous macros
soff Macro QuotedText:Vararg ; returns offset to a string
Local LocalText
.data
LocalText db QuotedText,0
.code
EXITM <offset LocalText>
Endm
msgx Macro qtext:VARARG
pusha
inv MessageBox,0,soff(qtext),0,0
popa
endm
uselib MACRO libname
include libname.inc
includelib libname.lib
ENDM
uselibs macro libs:vararg
for nlib,<libs>
include nlib.inc
includelib nlib.lib
endm
endm
uselibs user32,kernel32,comctl32,msvcrt,fpu
includelib \masm32\lib\ucrt.lib
.listall
.data?
hWin dd ?
buff db 100 dup (?)
buff2 db 100 dup (?)
sfloat dd ?
dfloat dq ?
atoflt dd ?
.data
xfloat dq 123.45677
.code
_atoflt PROTO C :DWORD,:DWORD
Program:
inv _atoflt,addr sfloat,soff("12345.67")
fld sfloat
fstp dfloat
inv crt_sprintf,addr buff2,soff("results= %f"),dfloat
inv MessageBox,0,addr buff2,0,0
; try fpu
inv FpuAtoFL,soff("12345.67"),addr sfloat,DEST_MEM4
.if eax==0
msgx "error in fpuatofl"
jmp wrap
.endif
fld sfloat
fstp dfloat
inv crt_sprintf,addr buff2,soff("results= %f"),dfloat
inv MessageBox,0,addr buff2,0,0
;might have just as well output to double to begin with
inv FpuAtoFL,soff("6543.21"),addr dfloat,DEST_MEM8
.if eax==0
msgx "error in fpuatofl"
jmp wrap
.endif
inv crt_sprintf,addr buff2,soff("results= %f"),dfloat
inv MessageBox,0,addr buff2,0,0
wrap:
inv ExitProcess, eax
end Program
Hi, it's me again....
I thought I'd just tack on here since it's a similar type of question.
Would someone like to show how to use strtoull in masm/uasm?
I'd appreciate it. I can't seem to get the appropriate declaration, and even if I did, I couldn't find where the results would be returned to in masm.
Ah, just discovered the actual name is _strtoull_l
now that I can call it, just need to figure out where the return value is.
and just discovered you can just call it with strtoull.
didn't need the underline at all. I made it too complicated from the beginning. Still looking for output however.
And finally guessed right. It's returned in eax:edx
e.g.
includelib \masm32\lib\ucrt.lib
.data?
dfloat dq ?
.code
strtoull PROTO C :DWORD,:DWORD,:DWORD
inv strtoull, soff("405edd3c07ee0b0b"),0,16 ; soff is my make a string function. I think it's SADD in masm32
mov dword ptr dfloat,eax
mov dword ptr dfloat+4,edx
inv crt_sprintf,addr buff2,soff("%f"),dfloat
inv MessageBox,0,addr buff2,soff("print res"),0
prints out 123.456789
Quote from: jimg on March 04, 2024, 05:15:29 PMjust discovered you can just call it with strtoull
Check the source of these strtoull timings (https://masm32.com/board/index.php?msg=127115). It's not in the Masm32 or Masm64 SDKs, so you have to grab it via LoadLibrary & GetProcAddress.
Windows OS msvcrt.dll have _strtoui64 function too and perhaps a bit faster than ucrtbase.dll strtoull.
_strtoui64 is indeed a bit faster than strtoull:
2681 cycles for 100 * Masm32 SDK hex2bin
25728 cycles for 100 * strtoull
1661 cycles for 100 * HexVal
18145 cycles for 100 * _strtoui64
EDIT: attachment removed - see reply #30
I could be wrong, but it looks to me like hex2bin does not put out a double (64 bit float).
I don't know why you're calling those "floats": they aren't, just unsigned integers.
But what's weird is that you're using the floating-point format specifier ("%f") and apparently getting the right answer. ?????
Quote from: jimg on March 04, 2024, 11:38:05 PMI could be wrong, but it looks to me like hex2bin does not put out a double (64 bit float).
You are perfectly right, Jim - sorry, my fault. Here are results for _strtoui64("1234567890.1234567890", 0, 10, 0)
AMD Athlon Gold 3150U with Radeon Graphics (SSE4)
17353 cycles for 100 * MasmBasic Val
175059 cycles for 100 * CRT sscanf
24912 cycles for 100 * _strtoui64
18031 cycles for 100 * MasmBasic Val
177988 cycles for 100 * CRT sscanf
25351 cycles for 100 * _strtoui64
17327 cycles for 100 * MasmBasic Val
175367 cycles for 100 * CRT sscanf
26482 cycles for 100 * _strtoui64
17739 cycles for 100 * MasmBasic Val
177129 cycles for 100 * CRT sscanf
24694 cycles for 100 * _strtoui64
18033 cycles for 100 * MasmBasic Val
174206 cycles for 100 * CRT sscanf
24456 cycles for 100 * _strtoui64
9 bytes for MasmBasic Val
18 bytes for CRT sscanf
34 bytes for _strtoui64
Real8 1234567890.123456716 MasmBasic Val
Real8 1234567890.123456716 CRT sscanf
Real8 1234567890.000000000 _strtoui64
Saving double to hex-format is fixed length and accurate.
Okay, here is the "quickie" I've been working on.
It's a simple program lets the user type in or paste a decimal number, an 8 character hex, or a 16 character hex, and converts whats put in to the other two types. I'm wanted it as a tool for something else I'm working on. Little did I know it would take a week for such a small, simple program.
Also, Microsoft thinks it's a virus! I included the source so you can see it's not. Assemble it yourself.
Microsoft has gotten worse and worse. Most of my programs are now considered a virus.
So, what's the simplest/smallest patch so it passes the virus test?
okay, minutes later. There is no where to add an attachment. When did this happen?
This really feels like a senior moment. How does one add an attachment now?
Exactly right, thank you.
Here's the stuff. Not a polished app, and needs a better sprintf format for decimal, but functional.
edit: zip removed.
Okay, I added a worthless manifest to this pig.
Let me know if you are still getting a virus warning.
edit: zip deleted, new one below
and while I'm making a total mess here----
Does any know how to fix this warning?
warning LNK4078: multiple ".drectve" sections found with different attributes (00000A00)
How do you give it the same attributes (whatever they are)?
I'm using this manifest-
OPTION DOTNAME
.drectve SEGMENT INFO DISCARD
db "'"
db '-manifestuac:level="requireAdministrator" uiAccess="false" '
db "'"
db '-manifestdependency:type="Win32"'
db ' name="Microsoft.Windows.Common-Controls"'
db ' version="6.0.0.0"'
db ' processorArchitecture="X86"'
db ' publicKeyToken="6595b64144ccf1df"'
db ' language="*"'
db '-manifest:embed'
.drectve ENDS
Did you fumble your Windows.inc?
\Masm32\include\windows.inc(156) : Error A2136: Symbol type conflict: BOOL
\Masm32\include\windows.inc(156): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\windows.inc(12164) : Error A2056: Symbol already defined: Flags
\Masm32\include\windows.inc(12164): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\windows.inc(12184) : Error A2056: Symbol already defined: Flags
\Masm32\include\windows.inc(12184): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\windows.inc(16530) : Error A2056: Symbol already defined: hInst
\Masm32\include\windows.inc(16530): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\windows.inc(16542) : Error A2056: Symbol already defined: hInst
\Masm32\include\windows.inc(16542): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\windows.inc(23408) : Error A2056: Symbol already defined: GUID
\Masm32\include\windows.inc(23408): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\winextra.inc(12329) : Error A2056: Symbol already defined: cStr
\Masm32\include\winextra.inc(12329): Included by
\Masm32\include\windows.inc(26889): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\winextra.inc(12795) : Error A2101: Macro nesting level too deep
\Masm32\include\winextra.inc(12795): Included by
\Masm32\include\windows.inc(26889): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\winextra.inc(12811) : Error A2101: Macro nesting level too deep
\Masm32\include\winextra.inc(12811): Included by
\Masm32\include\windows.inc(26889): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\winextra.inc(12823) : Error A2101: Macro nesting level too deep
\Masm32\include\winextra.inc(12823): Included by
\Masm32\include\windows.inc(26889): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\winextra.inc(12841) : Error A2101: Macro nesting level too deep
\Masm32\include\winextra.inc(12841): Included by
\Masm32\include\windows.inc(26889): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\winextra.inc(12853) : Error A2101: Macro nesting level too deep
\Masm32\include\winextra.inc(12853): Included by
\Masm32\include\windows.inc(26889): Included by
Tmp_File.asm(4): Main line code
\Masm32\include\user32.inc(1731) : Error A2143: Symbol redefinition: TRACKMOUSEEVENT
\Masm32\include\user32.inc(1731): Included by
MacroLoop(1): iteration 1: Macro called from
uselibs(4)[Tmp_File.asm]: Macro called from
Tmp_File.asm(38): Main line code
\Masm32\include\user32.inc(1811) : Error A2143: Symbol redefinition: MOUSE_EVENT
\Masm32\include\user32.inc(1811): Included by
MacroLoop(1): iteration 1: Macro called from
uselibs(4)[Tmp_File.asm]: Macro called from
Tmp_File.asm(38): Main line code
\Masm32\include\comctl32.inc(141) : Error A2143: Symbol redefinition: INITCOMMONCONTROLSEX
\Masm32\include\comctl32.inc(141): Included by
MacroLoop(1): iteration 3: Macro called from
uselibs(4)[Tmp_File.asm]: Macro called from
Tmp_File.asm(38): Main line code
Tmp_File.asm(55) : Error A2143: Symbol redefinition: DLGPROC
Tmp_File.asm(59) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(62) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(65) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(68) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(71) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(74) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(78) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(93) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(111) : Error A2048: Operands must be the same size: 1 - 2
Tmp_File.asm(150) : Error A2142: Unmatched block nesting: DlgProc
Tmp_File.asm: 174 lines, 1 passes, 94 ms, 0 warnings, 26 errors
I don't think so. At least I don't get those errors. Did you slip in another include that conflicts?
My total includes are:
include windows.inc
uselibs user32,kernel32,comctl32,msvcrt,fpu
includelib \masm32\lib\ucrt.lib
Quote from: jimg on March 05, 2024, 08:36:22 AMDid you slip in another include that conflicts?
No, and I have over 5,500 sources here that don't produce these errors.
My \Masm32\include\windows.inc is of 10 Jan 2012 and has 977,412 bytes.
The problem sits here:
.686p
.model flat, stdcall
.nolist
option casemap :none ; case sensitive
include windows.inc
Without this line,
Flags equals
flags (to quote one example). I wonder why it assembles on your machine :rolleyes:
My windows.inc is dated 1/9/2012
perhaps a newer one might have that problem?
It's a very small program. I just can't see it. Can you?
option casemap :none solves the problem, see above.
Well gee. How did that happen. Looking over many of my other programs, I have 1933 files with that line. Magic editing skill at work I guess. I'll upload a new version.
Thank for finding that, I had no idea what the problem was.
Latest fix. This was just meant to be a quickie. Ridiculous.
Quote from: jj2007 on March 05, 2024, 09:00:38 AMoption casemap :none solves the problem, see above.
Quote from: jimg on March 05, 2024, 09:06:44 AMWell gee. How did that happen. Looking over many of my other programs, I have 1933 files with that line. Magic editing skill at work I guess.
You might want to consider using
masm32rt.inc instead, which includes that statement as welll as other useful stuff.
Thanks for the thought. I considered it many years ago, and it just hides and loads way too much stuff I don't need, slowing down the compile time. I'm a little more of a minimalist than that.
Quote from: jimg on March 05, 2024, 10:54:41 AMslowing down the compile time
I made a series of tests. A simple Windows GUI program of about 100 lines takes:
- about 460 milliseconds to assemble with a minimal set of includes and libraries
- about 460 milliseconds with a simple include \masm32\include\masm32rt.inc
- about 520 milliseconds with include \masm32\MasmBasic\MasmBasic.inc
So the "slowdown" is zero milliseconds for masm32rt.inc and a whopping 60 milliseconds for the MasmBasic library (with currently 520 additional commands) :cool:
Yes, of course my feelings were from 15 or more years ago hardware. But I'm still a minimalist at heart :)
Well, then you'd better remember to include all those little bits and pieces.
15 years ago I would've agreed with you. I find as I get older that I want the machine to remember more and me to have to remember less stuff.
Hello,
Here is a quick _strtoui64 example :
include \masm32\include\masm32rt.inc
includelib ucrt.lib
_strtoui64 PROTO C :DWORD,:DWORD,:DWORD
.data
str1 db '65536',0
str2 db 'Value returned by'
db '_strtoui64 : %u',0
.data?
.code
start:
invoke _strtoui64,ADDR str1,\
0,10
invoke crt_printf,ADDR str2,eax
invoke ExitProcess,0
END start
Thanks erol.
I'm not clear on the difference between strtoui64 and strtoull, that is I'm not sure what the difference between the output, "unsigned __int64" and "unsigned long long" is, and which one I should use when.
Quote from: jimg on March 07, 2024, 01:01:22 AMThanks erol.
I'm not clear on the difference between strtoui64 and strtoull, that is I'm not sure what the difference between the output, "unsigned __int64" and "unsigned long long" is, and which one I should use when.
Both means same, 64bits long and long long is from newer standard C99 and __int64 is not standard C msvc private type.
So it doesn't matter which one I use. I'm not chunking vast amounts of data, so no need to run timing tests between the two.