flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Compiler Internals > timestamp directive or "%t" already in

Author
Thread Post new topic Reply to topic
DOS386



Joined: 08 Dec 2006
Posts: 1789
timestamp directive or "%t" already in
. .

. .

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: 11664
Location: In a galaxy far far too close
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
Assembly Artist


Joined: 16 Jun 2003
Posts: 5388
Location: Kraków, Poland
Re: [SUGG] timestamp directive

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: 1789
Re: [SUGG] timestamp directive
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: 11664
Location: In a galaxy far far too close
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: 1789
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: 11664
Location: In a galaxy far far too close
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: 1789
> 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: 11664
Location: In a galaxy far far too close
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
Assembly Artist


Joined: 16 Jun 2003
Posts: 5388
Location: Kraków, Poland
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: 11664
Location: In a galaxy far far too close
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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2013, Tomasz Grysztar.