Re: Embedded platforms (without FPU's), etc.
Date: Thu, 12 Apr 2018 21:50:10 -0600
> On Apr 2, 2018, at 3:27 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Sat, 31 Mar 2018, Philip Prindeville wrote:
>> Couple of questions. One is a broader question about tweaking the API so that it uses fewer “doubles” for get curl_easy_getinfo() call, in particular using fixed point since you might be running on a platform such as an embedded router with a MIPS-32 or ARMv6 CPU which doesn’t have floating-point… but is reasonably capable of 64-bit operations (shifting, adding, subtracting, etc).
> We've slowly been moving in that direction over time. As Harold mentioned, that easily conflicts with other limitation: not having 64 bit support.
I was looking at <include/curl/system.h> and it’s a little hairy. Can we just do something simple/stupid, like include <stdint.h> and if uint64_t is included then we support these timestamps, and if not, then we don’t?
> IMO, the most important thing would be to not have floating point operations in "the critical path" since most systems still have soft float support.
>> So we might want to express times as uint64_t’s as (tv.tv_sec * 1000000) + tv.usec.
> For what option(s) would this be used?
/* Fill in new entries below here! */
CURLINFO_TOTAL_TIME_T = CURLINFO_USECS + 50,
CURLINFO_NAMELOOKUP_TIME_T = CURLINFO_USECS + 51,
CURLINFO_CONNECT_TIME_T = CURLINFO_USECS + 52,
CURLINFO_PRETRANSFER_TIME_T = CURLINFO_USECS + 53,
CURLINFO_STARTTRANSFER_TIME_T = CURLINFO_USECS + 54,
CURLINFO_REDIRECT_TIME_T = CURLINFO_USECS + 55,
CURLINFO_APPCONNECT_TIME_T = CURLINFO_USECS_T + 56,
>> Not sure why some values like bytes downloaded need to be “doubles”. Again, uint64_t would be ideal here.
> I think we offer most of those values as 'curl_off_t' numbers if you use the modern versions.
I couldn’t figure out if that’s guaranteed to be 64-bits in all cases. Like here:
/* generic "safe guess" on old 32 bit style */
# define CURL_TYPEOF_CURL_OFF_T long
# define CURL_FORMAT_CURL_OFF_T "ld"
# define CURL_FORMAT_CURL_OFF_TU "lu"
# define CURL_SUFFIX_CURL_OFF_T L
# define CURL_SUFFIX_CURL_OFF_TU UL
# define CURL_TYPEOF_CURL_SOCKLEN_T int
I haven’t touched a System 370 since college, for instance… or a Watcom or Borland compiler, for that matter.
>> I can come up with a set of patches that support uint64_t’s in more places.
> Sure. If those changes actually make a difference in a real world application then I think those can be good improvements.
>> Lastly—as you might guess, I’m doing development for platforms which don’t have FPU’s—and I need to retrieve the delay from calling curl_easy_perform() and the socket completing a connect().
> And you can explain some of that time on floating point operations? Well then we should certainly make sure those don't happen.
>> Is there some easy way to use a callback that gets called immediately after the connect() completes?
> No, we have no such dedicated callback.
Could the debug function be overloaded?
>> For instance, the first time XFERFUNCTION gets called and then immediately unset the hook (inside the handler)?
> XFERFUNCTION may be called numerous times before the connect() completes if you have slow name lookup or otherwise slow network.
> libcurl is purposedly focused on transfers and doesn't really try to expose such specific events or states as "connect completed" within each transfer. libcurl also supports transfers without connects.
Received on 2018-04-13