triggering things with ethernet

Floats are really necessary if you need magnitude at the cost of absolute accuracy. Adding large and small float should be no issue, FPUs I have used always convert both operands to large, do the busyness then convert the result to small if that was asked for. However if you have an FPU anyway and you know how what you are doing why not use it, if this can simplify your work or speed up things or both.

rp2040 doesn't have an FPU

Oh I see. But I won't be surprised at all if people are using some FPU emulation which must come with it simply because "processing power is cheap, thinking is expensive". Justifiable but well, I'd have a hard time making myself to follow that path.

I said that both were long floats, the 8-byte thing.

It does have fp math operations in the hard rom, with some hardware assist. Looks like floating math ops take a few hundred ns.

I would also avoid using floats in ISRs. Just look what exceptions and faults your intended FP instruction might generate. You just don't want such things to happen in the clock ISR.

If you are using 64 to 128 bit entities (float or integer) better hope the load and store instructions are atomic.

Taking integer part of a float is a time consuming operation due to the de-normalization, unless the processor has a proper barrel shifter.

"int()" is expensive for a number in IEEE FP format unless the FP hardware has a barrel shifter - it will be glacially slow in an emulator

- slow enough that the computed answer will be out of date!

If you don't mind large systematic errors then do it your way!

It might be marginally faster to have the increment as a 4 byte real depending on the architecture.

Floating point for this is still a really bad idea even if you do have hardware assist.

Making them a 32 bit unsigned increment and a 64 bit sum would be a much more natural choice and then use the high 32 bit integer as the clock.

That still lets you have ~10^9 fine adjustments and integer operations on most modern CPUs are single cycle. BTW You will be lucky to get anywhere near 0.1ppm unless you control the temperature of the crystal...

It might be more sensible to accumulate the signed error relative to the system clock hardware value instead. That overflows much less often.

Taking the int() is time consuming, since it requires denormalization (shifting the mantissa by N bits) and remember to add the "hidden" bit. The situation is problematic with simple 8 bit processors, say

The problem can be improved by first doing the 0, 8, 16, 24,..56 bit shift by simple byte moves and then do the 1 to 7 bit shift the traditional way. Even this can be improved if 2-3 suitable byte resister are available and some shift and masking can be done for any combinations of 1 to 7 shifts.