flat assembler
Message board for the users of flat assembler.
Index
> Main > MASM to FASM, ADDR? |
Author |
|
LocoDelAssembly 22 Jan 2008, 15:40
The correct way is
Code: include 'win32ax.inc' start: invoke QueryPerformanceFrequency, timerFrequency test eax, eax jz hardwareNotAvailable invoke MessageBox, 0, "QueryPerformanceFrequency returned successfully", "OK", 0 ret hardwareNotAvailable: invoke MessageBox, 0, "Hardware not available", "Error", 0 ret align 8 ; Failed to me without this!! timerFrequency dq ? .end start Last edited by LocoDelAssembly on 22 Jan 2008, 15:49; edited 1 time in total |
|||
22 Jan 2008, 15:40 |
|
LocoDelAssembly 22 Jan 2008, 15:48
BTW, is documented somewhere that LARGE_INTEGER must be aligned? Because there is no warns at that respect on http://msdn2.microsoft.com/en-us/library/ms644905(VS.85).aspx
|
|||
22 Jan 2008, 15:48 |
|
calpol2004 22 Jan 2008, 18:50
Thankyou very much. It works .
Perculiar solution though. does it make sure that the memory is stored at an address which is a multiple of 8? Hmm, i shall have to scour the docs once more . . |
|||
22 Jan 2008, 18:50 |
|
LocoDelAssembly 22 Jan 2008, 20:12
http://bobmoore.mvps.org/Win32/w32tip75.htm
I have tried to step into the SYSCALL with WinDbg as a kernel debugger attached to a VirtualPC but the step into is not possible and I don't know how to stop at kernel mode |
|||
22 Jan 2008, 20:12 |
|
madmatt 22 Jan 2008, 20:15
If your going to Implement some timing functions, Here's some articles that might interest you:
http://www.mvps.org/directx/indexes/game_timing.htm QueryPerformanceCounter is covered, and how to use it in your games/gfx coding. there is also another method discussed for older OS compatibility. |
|||
22 Jan 2008, 20:15 |
|
madmatt 22 Jan 2008, 20:24
calpol2004 wrote:
Not really, but If you want to save a few cycles, it would be good to put an 'align 8' just before the variable. Or a string of Quad sized variables. |
|||
22 Jan 2008, 20:24 |
|
calpol2004 23 Jan 2008, 12:25
i always thought align 8 was just an optimization that made sure that the memory was taken from the ram from the start of the variable so that the I/O controller doesn't have to throw away the unwanted adjacent bytes.
I remember reading something about it in "art of assembly" about how reading from addressed which are multiples of 4 or 2 is faster that odd numbers, but shouldnt it still work anyway? And that is an interesting article about game timings, i've always updated the same amount each fps. which is dum since if the pc isn't good enough it will play the game in slow motion. calculating the distance the object should of moved by knowing the last time the frame was drawn is much more logical. |
|||
23 Jan 2008, 12:25 |
|
LocoDelAssembly 23 Jan 2008, 16:50
I don't understand why functions like InterlockedIncrement warns you about alignment requirements while this one says absolutely nothing and even the MVP seems to be somewhat surprised since he spent hours to find the solution and guessed what was the problem rather than pointing to documentation.
[edit]I misunderstood madmatt response so now I edited to make my post context independent[/edit] Last edited by LocoDelAssembly on 24 Jan 2008, 15:36; edited 1 time in total |
|||
23 Jan 2008, 16:50 |
|
madmatt 24 Jan 2008, 11:51
calpol2004 wrote: i always thought align 8 was just an optimization that made sure that the memory was taken from the ram from the start of the variable so that the I/O controller doesn't have to throw away the unwanted adjacent bytes. I should clarify, for the application you posted, alignment wouldn't give you any real benefit. I'm not sure, but I think alignment has something to do with the way the CPU fetch's data, whether it has to do one 8-byte fetch vs 2 4-byte fetches. I would agree with "art of assembly" that aligned data is better than unaligned data, especially in the case of MMX/SSE/SSE2 operations. Most CPU instructions can work with unaligned data, only in certain SSE instructions require that data be aligned. |
|||
24 Jan 2008, 11:51 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.