Proposal re: timers
Locked
|
Hi Folks,
I'd like to propose that some types used in the timer module be 64-bits wide instead of 32. At first, I was hesitant about that, but I see that u64 is used in that the platform module. The reason I propose this is that, being selfish, my timer counter consists of two 32-bit registers updated at 50 MHz. It doesn't take long for tmr.read(0) to just return a saturated value (by my implementation).
Matt
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Hi,
On Fri, Apr 29, 2011 at 4:18 PM, Matt Wilbur <[hidden email]> wrote:
Hi Folks, The main problem with this is that you can't export the full value of the counter to Lua. Lua uses doubles (by default) for its number type and doubles can't represent the full range of an unsigned 64-bit integer. I don't know of any good way to get around this.
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Maybe treat the timer value as a high and low value and use a lua table to store the value. Have several helper functions to add, subtract, divide, or any other math operations. From: Bogdan Marinescu <[hidden email]> To: eLua Users and Development List (www.eluaproject.net) <[hidden email]> Sent: Friday, April 29, 2011 8:27 AM Subject: Re: [eLua-dev] Proposal re: timers Hi, On Fri, Apr 29, 2011 at 4:18 PM, Matt Wilbur <[hidden email]> wrote:
Hi Folks, The main problem with this is that you can't export the full value of the counter to Lua. Lua uses doubles (by default) for its number type and doubles can't represent the full range of an unsigned 64-bit integer. I don't know of any good way to get around this.
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Apr 29, 2011 at 4:39 PM, Tim michals <[hidden email]> wrote:
This is a possibility, as is having an u64 as a special data type (based on userdatum with metatables that implement methods such as __add, __mul ...). A bit cumbersome to use probably, but doable.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Okay, something to think about. I'll take on adding the lua stuff as that will be a good learning experience.
For the time being, I'm going to add stop and clear methods to the tmr table.
Matt
On Fri, Apr 29, 2011 at 9:41 AM, Bogdan Marinescu <[hidden email]> wrote:
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
The other options, which I personally like better, is to move everything related to timer counter values out of the generic platform code. That is, the platform specific code already has to do work in microseconds (delay, for example). So, push all responsibility to convert from ticks to microseconds back to the platform specific code. I personally feel the timer should deal in the currency of time only.
Code that uses platform_timer_get_diff_us could instead call something like platform_timer_get_elapsed_us which returns a us value. Thoughts? Below is an example: int platform_uart_recv( unsigned id, unsigned timer_id, s32 timeout ) { timer_data_type tmr_start, tmr_crt; int res; if( timeout == 0 )
return cmn_recv_helper( id, timeout ); else if( timeout == PLATFORM_UART_INFINITE_TIMEOUT ) return cmn_recv_helper( id, timeout ); else { // Receive char with the specified timeout
tmr_start = platform_timer_op( timer_id, PLATFORM_TIMER_OP_START, 0 ); while( 1 ) { if( ( res = cmn_recv_helper( id, 0 ) ) >= 0 ) break;
tmr_crt = platform_timer_op( timer_id, PLATFORM_TIMER_OP_READ, 0 ); if( platform_timer_get_elapsed_us( timer_id ) >= timeout ) break; }
return res; } } Matt
On Fri, Apr 29, 2011 at 9:58 AM, Matt Wilbur <[hidden email]> wrote: Okay, something to think about. I'll take on adding the lua stuff as that will be a good learning experience. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Apr 29, 2011 at 5:42 PM, Matt Wilbur <[hidden email]> wrote:
The other options, which I personally like better, is to move everything related to timer counter values out of the generic platform code. That is, the platform specific code already has to do work in microseconds (delay, for example). So, push all responsibility to convert from ticks to microseconds back to the platform specific code. I personally feel the timer should deal in the currency of time only. If I understand correctly, platform_timer_get_elapsed_us is automatically "tied" to the latest invocation of "tmr.start" or "tmr.read". This breaks in a number of situations, for example if you want to check timeouts against a start time at different times in your program:
local start_time = tmr.start(0) <code here> if tmr.gettimedif( 0, start_time, tmr.read(0)) then .... <more time consuming code here> if tmr.gettimediff( 0, start_time, tmr.read(0)) then ....
The point is that you make an explicit reference implicit with your approach, which generally results in reduced functionality. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Apr 29, 2011 at 11:00 AM, Bogdan Marinescu <[hidden email]> wrote:
Fair enough. But we could achieve the explicit reference and still deal in us only. Perhaps, as a platform_timer_get_time instead of get_count. Again, this pushes all the 64-bit math back into the platform-specific code and deals in the common currency of us.
Matt
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Apr 29, 2011 at 6:23 PM, Matt Wilbur <[hidden email]> wrote:
You mean change tmr.start() and tmr.read() to return the value of the timer counter's converted to us instead just the value of the timer itself? Interesting. I think I can live with this. I'll think about the implications a bit more, but I don't see anything wrong with it at this point. It shouldn't even break compatibility with previous eLua programs.
Thanks for the idea! Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Apr 29, 2011 at 11:37 AM, Bogdan Marinescu
<[hidden email]> wrote: > > > On Fri, Apr 29, 2011 at 6:23 PM, Matt Wilbur <[hidden email]> wrote: >> >> >> On Fri, Apr 29, 2011 at 11:00 AM, Bogdan Marinescu >> <[hidden email]> wrote: >>> >>> On Fri, Apr 29, 2011 at 5:42 PM, Matt Wilbur <[hidden email]> wrote: >>>> >>>> The other options, which I personally like better, is to move everything >>>> related to timer counter values out of the generic platform code. That is, >>>> the platform specific code already has to do work in microseconds (delay, >>>> for example). So, push all responsibility to convert from ticks to >>>> microseconds back to the platform specific code. I personally feel the >>>> timer should deal in the currency of time only. >>>> Code that uses platform_timer_get_diff_us could instead call something >>>> like platform_timer_get_elapsed_us which returns a us value. >>> >>> If I understand correctly, platform_timer_get_elapsed_us is automatically >>> "tied" to the latest invocation of "tmr.start" or "tmr.read". This breaks in >>> a number of situations, for example if you want to check timeouts against a >>> start time at different times in your program: >>> local start_time = tmr.start(0) >>> <code here> >>> if tmr.gettimedif( 0, start_time, tmr.read(0)) then .... >>> <more time consuming code here> >>> if tmr.gettimediff( 0, start_time, tmr.read(0)) then .... >>> The point is that you make an explicit reference implicit with your >>> approach, which generally results in reduced functionality. >> >> Fair enough. But we could achieve the explicit reference and still deal >> in us only. Perhaps, as a platform_timer_get_time instead of get_count. > > You mean change tmr.start() and tmr.read() to return the value of the timer > counter's converted to us instead just the value of the timer itself? > Interesting. I think I can live with this. I'll think about the implications > a bit more, but I don't see anything wrong with it at this point. It > shouldn't even break compatibility with previous eLua programs. > Thanks for the idea! This is something I've actually considered a few times as well, though I haven't gone through all the implications. I suppose there are some downsides if the register value was providing resolution better than us, but in Lua going beyond that resolution is probably overly optimistic in terms of utility within the Lua VM unless the MCUs we're working with suddently are running a few orders of magnitude faster. Another comment going back to the u64 suggestion: If we did want something like that to work Lua LNUM would help there. I think if one has both LNUM_DOUBLE and LNUM_INT64 defined you would at least get to keep 63-bits of integer precision I think. I'm not sure exactly what decision it makes regarding precision when you perform operations on a 64-bit int, though. Still, I would worry that this might get complicated since presumably we'd have to bump up the minimum integer mode to 64-bit ints which would add to the overhead. LNUM also provides the LNUM_LDOUBLE which would give you an 80+ bit mantissa... While I'm not suggesting the above is a good or the right way to go, I did start merging the LNUM patch into eLua, though I haven't finished the last bits of it, nor have I tested it. I think, however, it should be rather worthwhile for most of our platforms which don't have FPUs. For those unfamiliar: LNUM allows Lua's numeric type to support added precision and for it to degrade math operations to integer ones when doing full floating point calculations is unnecessary. The author claims about 30% speed improvements for platforms without FPUs. > Best, > Bogdan >> >> Matt >> >> >>> >>> Best, >>> Bogdan >>>> >>>> On Fri, Apr 29, 2011 at 9:58 AM, Matt Wilbur <[hidden email]> wrote: >>>>> >>>>> Okay, something to think about. I'll take on adding the lua stuff as >>>>> that will be a good learning experience. >>>>> For the time being, I'm going to add stop and clear methods to the tmr >>>>> table. >>>>> Matt >>>>> >>>>> On Fri, Apr 29, 2011 at 9:41 AM, Bogdan Marinescu >>>>> <[hidden email]> wrote: >>>>>> >>>>>> >>>>>> On Fri, Apr 29, 2011 at 4:39 PM, Tim michals <[hidden email]> >>>>>> wrote: >>>>>>> >>>>>>> Maybe treat the timer value as a high and low value and use a lua >>>>>>> table to store the value. Have several helper functions to add, subtract, >>>>>>> divide, or any other math operations. >>>>>> >>>>>> This is a possibility, as is having an u64 as a special data type >>>>>> (based on userdatum with metatables that implement methods such as __add, >>>>>> __mul ...). A bit cumbersome to use probably, but doable. >>>>>> Best, >>>>>> Bogdan >>>>>>> >>>>>>> ________________________________ >>>>>>> From: Bogdan Marinescu <[hidden email]> >>>>>>> To: eLua Users and Development List (www.eluaproject.net) >>>>>>> <[hidden email]> >>>>>>> Sent: Friday, April 29, 2011 8:27 AM >>>>>>> Subject: Re: [eLua-dev] Proposal re: timers >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On Fri, Apr 29, 2011 at 4:18 PM, Matt Wilbur <[hidden email]> >>>>>>> wrote: >>>>>>> >>>>>>> Hi Folks, >>>>>>> I'd like to propose that some types used in the timer module be >>>>>>> 64-bits wide instead of 32. At first, I was hesitant about that, but I see >>>>>>> that u64 is used in that the platform module. The reason I propose this is >>>>>>> that, being selfish, my timer counter consists of two 32-bit registers >>>>>>> updated at 50 MHz. It doesn't take long for tmr.read(0) to just return a >>>>>>> saturated value (by my implementation). >>>>>>> >>>>>>> The main problem with this is that you can't export the full value of >>>>>>> the counter to Lua. Lua uses doubles (by default) for its number type and >>>>>>> doubles can't represent the full range of an unsigned 64-bit integer. I >>>>>>> don't know of any good way to get around this. >>>>>>> Best, >>>>>>> Bogdan >>>>>>> >>>>>>> _______________________________________________ >>>>>>> eLua-dev mailing list >>>>>>> [hidden email] >>>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> eLua-dev mailing list >>>>>>> [hidden email] >>>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> eLua-dev mailing list >>>>>> [hidden email] >>>>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> eLua-dev mailing list >>>> [hidden email] >>>> https://lists.berlios.de/mailman/listinfo/elua-dev >>>> >>> >>> >>> _______________________________________________ >>> eLua-dev mailing list >>> [hidden email] >>> https://lists.berlios.de/mailman/listinfo/elua-dev >>> >> >> >> _______________________________________________ >> eLua-dev mailing list >> [hidden email] >> https://lists.berlios.de/mailman/listinfo/elua-dev >> > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On Fri, Apr 29, 2011 at 12:37 PM, Bogdan Marinescu <[hidden email]> wrote:
Yes, that's the idea.
Happy to contribute. Let me know what you decide and I can assist in making any changes if you want. Matt
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by jbsnyder
On Fri, Apr 29, 2011 at 1:41 PM, James Snyder <[hidden email]> wrote: On Fri, Apr 29, 2011 at 11:37 AM, Bogdan Marinescu I guess the question is, does code ever read the count and *not* convert it to a time value? This all came up in my mind as I was designed my platform specific code and I spent (too) much time thinking about it. I came to the strong opinion that tick count should be a platform specific measure hidden by the module and microseconds should be the only type of value that it provides to the eLua code. If higher resolution is needed, then I think the answer is to go to nano seconds, not ticks.
Matt
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Matt Wilbur
Hi,
On Sun, May 1, 2011 at 12:18 PM, Matt Wilbur <[hidden email]> wrote:
I found a problem with this, unfortunately: it can severely limit your ability to wait for a long time/measure long intervals of time. That is, it makes the resolution a bit too high. If we return everything in microseconds, a 32-bit variable that counts microseconds will overflow after about 1.2 hours. This might seem a lot, but there are surely a lot of applications out there which need to measure time intervals longer than 1 hour. Currently, if we set the timer's clock to 1KHz (for example), skip tmr.gettimediff and compute the difference manually instead, we can get much longer delays.
All in all, I'm still not sure how to fix this properly. I was planning to add a "system wide timer" to eLua (soon) and I was also planning to make that ms (not us) accurate. This fits much better with the current model. We could add a 64-bit data type specifically for handling timers, but I can't really estimate how much overhead this will bring.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, May 10, 2011 at 12:47 AM, Bogdan Marinescu <[hidden email]> wrote: Hi, Yes, unless 64-bits are used, it is always possible to get pinched on one end or the other. Not all constraints can be satisfied. i.e. if the timer is 1 kHz, most of the least significant bits of the us wait are "wasted". Clearly, you can't wait for 1us in this case. So which case is less evil? Is 1.2 hours and a 1 kHz clock a valid use case? I don't know. I would argue that, in that case, one has to query the timer for the max wait and add iterations to get to 1.2 hours from the maximum rate.
At one point, I thought about supporting multiple time resolutions. But, again, you can always get pinched somewhere. Personally, I am avoiding floats too. I still really think that ticks is not a good metric to use. But that's just one guy's opinion.
Matt
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, May 10, 2011 at 4:19 PM, Matt Wilbur <[hidden email]> wrote:
I agree with you, however: - ticks have the advantage of allowing for flexible timer resolutions (while changing them to us or other fixed unit invalidates this)
- I don't really have a better option at the moment :) If it wasn't for integer only Lua we could still expose u64 values to Lua. Doubles can cover integers up to 2**53 - 1 (or something similar) so while we can't expose 64 bits the 53-bit counters will still take quite a while before they overflow. However, integer only Lua uses 32-bit numbers which simply doesn't provide enough resolution. Aaaargh. This is frustrating :)
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Maybe this might be over kill: There is two timer interfaces: - System Level API - Simple single timer for basic general time keeping, with 10ms or using a Realtime clock. - Get time - High resolution timer API - ie http://export.writer.zoho.com/public/rreginelli/Chapter-5---High-Resolution-Timers-Final1/fullpage - Allows for 32 bit and 64 bit machines.
- Use the standard POSIX interval timer API From: Bogdan Marinescu <[hidden email]> To: eLua Users and Development List (www.eluaproject.net) <[hidden email]> Sent: Tuesday, May 10, 2011 9:17 AM Subject: Re: [eLua-dev] Proposal re: timers On Tue, May 10, 2011 at 4:19 PM, Matt Wilbur <[hidden email]> wrote:
I agree with you, however: - ticks have the advantage of allowing for flexible timer resolutions (while changing them to us or other fixed unit invalidates this)
- I don't really have a better option at the moment :) If it wasn't for integer only Lua we could still expose u64 values to Lua. Doubles can cover integers up to 2**53 - 1 (or something similar) so while we can't expose 64 bits the 53-bit counters will still take quite a while before they overflow. However, integer only Lua uses 32-bit numbers which simply doesn't provide enough resolution. Aaaargh. This is frustrating :)
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Tue, May 10, 2011 at 9:48 AM, Tim michals <[hidden email]> wrote:
> Maybe this might be over kill: > > There is two timer interfaces: > - System Level API > - Simple single timer for basic general time keeping, with 10ms or > using a Realtime clock. > - Get time I think this is something that's been on the table for a general low resolution timer facility since there are a lot of cases currently where individual operations need a timer that isn't terribly high resolution and one ends up using multiple timers because one is consumed by peripherals like the UARTS (which don't need high resolution timers for timeouts). MMCFS/SDCard/FatFs support and LuaRPC also could use this facility as well as numerous other components leaving timers free for the end user for specific applications. > > - High resolution timer API > - ie > http://export.writer.zoho.com/public/rreginelli/Chapter-5---High-Resolution-Timers-Final1/fullpage > - Allows for 32 bit and 64 bit machines. > - Use the standard POSIX interval timer API This is one approach that occurred to me when this discussion got started where one is stuck with a bit of a tradeoff. Something like the POSIX approach might be a good one, although I wouldn't necessarily make it a goal to match the standard POSIX API. We're not going to be "creating" and "deleting" timers more, I would presume, configuring existing timers within their available limitations and using more standardized units to request intervals. > > > > > > ________________________________ > From: Bogdan Marinescu <[hidden email]> > To: eLua Users and Development List (www.eluaproject.net) > <[hidden email]> > Sent: Tuesday, May 10, 2011 9:17 AM > Subject: Re: [eLua-dev] Proposal re: timers > > > > On Tue, May 10, 2011 at 4:19 PM, Matt Wilbur <[hidden email]> wrote: > > > On Tue, May 10, 2011 at 12:47 AM, Bogdan Marinescu > <[hidden email]> wrote: > > Hi, > > On Sun, May 1, 2011 at 12:18 PM, Matt Wilbur <[hidden email]> wrote: > > > On Fri, Apr 29, 2011 at 12:37 PM, Bogdan Marinescu > <[hidden email]> wrote: > > > On Fri, Apr 29, 2011 at 6:23 PM, Matt Wilbur <[hidden email]> wrote: > > > On Fri, Apr 29, 2011 at 11:00 AM, Bogdan Marinescu > <[hidden email]> wrote: > > On Fri, Apr 29, 2011 at 5:42 PM, Matt Wilbur <[hidden email]> wrote: > > The other options, which I personally like better, is to move everything > related to timer counter values out of the generic platform code. That is, > the platform specific code already has to do work in microseconds (delay, > for example). So, push all responsibility to convert from ticks to > microseconds back to the platform specific code. I personally feel the > timer should deal in the currency of time only. > Code that uses platform_timer_get_diff_us could instead call something like > platform_timer_get_elapsed_us which returns a us value. > > If I understand correctly, platform_timer_get_elapsed_us is automatically > "tied" to the latest invocation of "tmr.start" or "tmr.read". This breaks in > a number of situations, for example if you want to check timeouts against a > start time at different times in your program: > local start_time = tmr.start(0) > <code here> > if tmr.gettimedif( 0, start_time, tmr.read(0)) then .... > <more time consuming code here> > if tmr.gettimediff( 0, start_time, tmr.read(0)) then .... > The point is that you make an explicit reference implicit with your > approach, which generally results in reduced functionality. > > Fair enough. But we could achieve the explicit reference and still deal in > us only. Perhaps, as a platform_timer_get_time instead of get_count. > > You mean change tmr.start() and tmr.read() to return the value of the timer > counter's converted to us instead just the value of the timer itself? > > Yes, that's the idea. > > > Interesting. I think I can live with this. I'll think about the implications > a bit more, but I don't see anything wrong with it at this point. It > shouldn't even break compatibility with previous eLua programs. > Thanks for the idea! > > I found a problem with this, unfortunately: it can severely limit your > ability to wait for a long time/measure long intervals of time. That is, it > makes the resolution a bit too high. If we return everything in > microseconds, a 32-bit variable that counts microseconds will overflow after > about 1.2 hours. This might seem a lot, but there are surely a lot of > applications out there which need to measure time intervals longer than 1 > hour. Currently, if we set the timer's clock to 1KHz (for example), skip > tmr.gettimediff and compute the difference manually instead, we can get much > longer delays. > All in all, I'm still not sure how to fix this properly. I was planning to > add a "system wide timer" to eLua (soon) and I was also planning to make > that ms (not us) accurate. This fits much better with the current model. We > could add a 64-bit data type specifically for handling timers, but I can't > really estimate how much overhead this will bring. > > Yes, unless 64-bits are used, it is always possible to get pinched on one > end or the other. Not all constraints can be satisfied. i.e. if the timer > is 1 kHz, most of the least significant bits of the us wait are "wasted". > Clearly, you can't wait for 1us in this case. So which case is less evil? > Is 1.2 hours and a 1 kHz clock a valid use case? I don't know. I would > argue that, in that case, one has to query the timer for the max wait and > add iterations to get to 1.2 hours from the maximum rate. > At one point, I thought about supporting multiple time resolutions. But, > again, you can always get pinched somewhere. Personally, I am avoiding > floats too. I still really think that ticks is not a good metric to use. > But that's just one guy's opinion. > > I agree with you, however: > - ticks have the advantage of allowing for flexible timer resolutions (while > changing them to us or other fixed unit invalidates this) > - I don't really have a better option at the moment :) > If it wasn't for integer only Lua we could still expose u64 values to Lua. > Doubles can cover integers up to 2**53 - 1 (or something similar) so while > we can't expose 64 bits the 53-bit counters will still take quite a while > before they overflow. However, integer only Lua uses 32-bit numbers which > simply doesn't provide enough resolution. Aaaargh. This is frustrating :) > Best, > Bogdan > > Best, > Bogdan > > > On Fri, Apr 29, 2011 at 9:58 AM, Matt Wilbur <[hidden email]> wrote: > > Okay, something to think about. I'll take on adding the lua stuff as that > will be a good learning experience. > For the time being, I'm going to add stop and clear methods to the tmr > table. > Matt > > On Fri, Apr 29, 2011 at 9:41 AM, Bogdan Marinescu > <[hidden email]> wrote: > > > On Fri, Apr 29, 2011 at 4:39 PM, Tim michals <[hidden email]> wrote: > > Maybe treat the timer value as a high and low value and use a lua table to > store the value. Have several helper functions to add, subtract, divide, or > any other math operations. > > This is a possibility, as is having an u64 as a special data type (based on > userdatum with metatables that implement methods such as __add, __mul ...). > A bit cumbersome to use probably, but doable. > Best, > Bogdan > > ________________________________ > From: Bogdan Marinescu <[hidden email]> > To: eLua Users and Development List (www.eluaproject.net) > <[hidden email]> > Sent: Friday, April 29, 2011 8:27 AM > Subject: Re: [eLua-dev] Proposal re: timers > > Hi, > > On Fri, Apr 29, 2011 at 4:18 PM, Matt Wilbur <[hidden email]> wrote: > > Hi Folks, > I'd like to propose that some types used in the timer module be 64-bits wide > instead of 32. At first, I was hesitant about that, but I see that u64 is > used in that the platform module. The reason I propose this is that, being > selfish, my timer counter consists of two 32-bit registers updated at 50 > MHz. It doesn't take long for tmr.read(0) to just return a saturated value > (by my implementation). > > The main problem with this is that you can't export the full value of the > counter to Lua. Lua uses doubles (by default) for its number type and > doubles can't represent the full range of an unsigned 64-bit integer. I > don't know of any good way to get around this. > Best, > Bogdan > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Tim Michals
Hi,
On Tue, May 10, 2011 at 5:48 PM, Tim michals <[hidden email]> wrote:
I've been thinking about that too. The main problem I have with this is that it might confuse the users (and you have to remember that eLua is not targeted mostly towards experienced programmers). I'm trying to keep this is as simple as possible. I didn't dismiss the idea yet though.
I had another idea yesterday: change integer only Lua to use 64-bit integers instead of 32-bit ones. This will improve overall usability (not only timer resolution) and I _think_ the performance impact won't be that serious (maybe offer a choice for integer only Lua: 32-bit or 64-bit). In this case I'd go with the solution presented in one of my previous e-mails: 52-bit timers (it turns out they are 52, not 53: http://lua-users.org/wiki/FloatingPoint). I believe in this case we can safely return us as our times values; if my calculations are correct, a 52-bit timer with a 1us resolution will overflow after ~142 years. I believe most applications will find this very reasonable :)
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |