flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > timestamp directive or "%t" already in

Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 19 Feb 2012, 10:59
. .

. .

timestamp 1980-01-01T00:00:00

will brew UINT32 representing timestamp given

timestamp

will brew UINT32 representing current time

--------------------------------------------------

FASM already has the conversion routine, it's (strangely) in SYSTEM.INC - so one could move the conversion into ASSEMBLE.INC and keep only peek_timestamp in SYSTEM.INC. Alternatively timestamp32 and timestamp64 to brew 32-bit or 64-bit timestamps.

EDIT : only subject


Last edited by DOS386 on 19 Feb 2012, 13:41; edited 1 time in total
Post 19 Feb 2012, 10:59
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 19 Feb 2012, 11:38
Why restrict yourself to only one timestamp possibility? And which timestamp format standard would you suggest following anyway?

I would suggest instead that you can use a macro for both of these operations and it would give you the flexibility to implement any of the integer coding standards you require.

BTW: I trust you did not forget about %t.
Post 19 Feb 2012, 11:38
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 19 Feb 2012, 13:09
DOS386 wrote:
FASM already has the conversion routine, it's (strangely) in SYSTEM.INC
That should not be strange considering that it is a documented part of fasm's OS abstraction interface. In my abandoned attempt to document fasm's internals I managed to at least document the fasm's interface (which is a useful information for the purpose of porting fasm to a new OS) and there you can find section about timestamp:
The [unfinished] official guide to flat assembler internals, section 2.6 wrote:
The "make_timestamp" routine should return the valid timestamp in the EAX.
This value should contain current system time converted to the number of
seconds since the 1-1-1970 00:00:00 (some operating systems already use the
timestamp format for the system time, so the conversion is not needed there).
And what you get with "%t" symbol during the assembly is exactly the value returned by this routine.


Last edited by Tomasz Grysztar on 19 Feb 2012, 13:48; edited 1 time in total
Post 19 Feb 2012, 13:09
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 19 Feb 2012, 13:36
Actually "%t" seems to cover most of this issue, except:

* 64-bit timestamps
* Other-than-now timestamps ("%t=1980-01-01T00:00:00" ???)

> not be strange considering that it is a
> documented part of fasm's OS abstraction interface

OK ... one could just split the "6-to-1" conversion from "peek-6-from-the-OS", as it would be needed for other-than-now timestamps.

AFAIK 32-bit timestamps will die in 2038:

Image


Last edited by DOS386 on 19 Feb 2012, 13:38; edited 1 time in total
Post 19 Feb 2012, 13:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 19 Feb 2012, 13:38
There is no reason that %t cannot return a 64-bit value in the future. It might be 32-bit today, but tomorrow ...?
Post 19 Feb 2012, 13:38
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 19 Feb 2012, 13:40
But having the very same "%t" returning 64-bit instead of 32-bit will break things (or would break if anyone used it ...).
Post 19 Feb 2012, 13:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 19 Feb 2012, 13:42
Why? So far %t has always returned a positive number less than 31-bit. %t can continue to return a positive number after April 2038. Where is the problem?
Post 19 Feb 2012, 13:42
View user's profile Send private message Visit poster's website Reply with quote
DOS386



Joined: 08 Dec 2006
Posts: 1903
DOS386 19 Feb 2012, 13:46
> Where is the problem?

In C and C+++ compilers. "int" is unknown size (used to be usually 32-bit) and usually signed. Set your clock to 2040 and enjoy various apps crashing Very Happy
Post 19 Feb 2012, 13:46
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 19 Feb 2012, 13:47
fasm != C or C+++ [sic], thankfully.
Post 19 Feb 2012, 13:47
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 19 Feb 2012, 13:57
Well, I set my clock to 2050 and assembled:
Code:
dq %t    
I happily got unsigned value. Wink
Post 19 Feb 2012, 13:57
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 28 Feb 2012, 01:42
Bonus points to anyone that implements a macro to do full conversion to and from RFC2550 and a full 64-bit signed %t value. Wink
Post 28 Feb 2012, 01:42
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.