Double represented in IEEE 64-bit precision

Go To Last Post
64 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
My conclusion is fairly straightforward.
  1. The libc.a functions should ALWAYS use jmp/call to external functions. All the functions are already in libc.a so there is no need for -lm
  2. A separately compiled libm.a could provide its own internal functions that it accesses with rjmp/rcall
[...] My personal preference is that externals should ALWAYS be jmp/call.
Whatever the conclusion and preferences are...

...some will have to actually *do* the code review and actually *do* according changes as needed.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems to me that the possibility of -ffixed would be even more restrictive on 64-bit doubles. https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=898389#898389
How often is -ffixed actually used?
When it is used, is it usually because it's wanted in an interrupt handler?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That restriction is not specific to a specific feature like 64-bit doubles, it's for all code in the support libraries. Less registers make it harder to write efficient asm code, of course. But it's only 6 registers: R2-R7.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
That restriction is not specific to a specific feature like 64-bit doubles, it's for all code in the support libraries. Less registers make it harder to write efficient asm code, of course. But it's only 6 registers: R2-R7.
It's more important for 64-bit.
Two operands and a result could already be 24 registers.
Add R2-R7 and that makes 30 registers.
Two more for the MUL target and one is up to the full 32.
Talk about register pressure.
I've read the float multiplication code and I'm pretty sure that I could write something similar for double.
Without R2-R7, I rather suspect that I would have to start using the stack.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
Talk about register pressure.

I've read the float multiplication code and I'm pretty sure that I could write something similar for double.
Without R2-R7, I rather suspect that I would have to start using the stack.

Talk about if the feature is sensible on 8-bit machine ;-)

Just imagine you had a 6502 and you won't complain any more, he he

Of course you can use stack. Set up a frame pointer, set up a stack space and use it.

And let me guess: vanilla C from libgcc don't manage it without stack, either... You won't be less smart than GCC in using stack for such a small program, so don't worry.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SprinterSB wrote:
skeeve wrote:
Talk about register pressure.

I've read the float multiplication code and I'm pretty sure that I could write something similar for double.
Without R2-R7, I rather suspect that I would have to start using the stack.

Talk about if the feature is sensible on 8-bit machine ;-)
OK.
If the gcc framework can handle it, a couple things could be done to speed up double precision arithmetic.
To meet ANSI and IEEE standards, eight bytes are not necessary.
We could use seven or even six bytes.
Also, we could use base 256.
In that case, float would have to become at least five bytes.
Quote:

Just imagine you had a 6502 and you won't complain any more, he he

Of course you can use stack. Set up a frame pointer, set up a stack space and use it.

And let me guess: vanilla C from libgcc don't manage it without stack, either... You won't be less smart than GCC in using stack for such a small program, so don't worry.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a request that would be invaluable for simple users learning about computers and the Arduino. I have two college students and an 11 year old eager younger brother diving in to this stuff, and I hate to think of the frustration that could develop and turn them off.

Could you guys put together a simple summary of the situation as it stands, so we know what bounds to live within? Primarily relative to what you get when you simply download the Arduino IDE and do stuff. For example:

"Doubles" are the same as float, 32 bit IEEE.
+-*/ work and work correctly.
sin(), cos(), tan(), exp() appear to work but sometimes return grossly incorrect results.
or
sin(), cos(), tan(), exp() appear to work but sometimes return slightly incorrect results, for example in the 5th decimal digit.
Do this, don't do that.
etc.

An appendix for those who might do commandline or eclipse, but don't want to get into the gory ins and outs and difficult situations with the compiler. "Run your compiler like this and you will get this set of functionality: This will work, this will not, the other thing will be real slow (Or fast)"

It *sounds like you guys could put together a couple three recipes and bullets documenting the situation with that recipe.

In time I expect that the avr-gcc community will fix it up according to their personal wisdom, but in the mean time please make a map so that simple users trying to learn and use the Arduino can avoid the landmines and have a good experience! We don't need everything to be perfect, we can work around mis-features and brokenness - just tell us what the deal is!

Perhaps it could be a sticky, be well publicized.

Thank you in advance.

--Ray

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ray

  • Avr-gcc only supports 32 bit IEEE754
  • This means double and float are the same width and operate identically.
  • As long as you link with libm.a then + -/× and sin cos tan all work as accurately as 32 bit allows (about 7.5 digits of accuracy). The corollary of that is that if you don't then you get generic code designed for a 32bit compiler that is slow, bloated and inaccurate,
  • Float use in 8 bit micros is very rarely appropriate and it would be unwise to teach an 11 year old otherwise.
Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

RnSC wrote:
I have a request that would be invaluable for simple users learning about computers and the Arduino. I have two college students and an 11 year old eager younger brother diving in to this stuff, and I hate to think of the frustration that could develop and turn them off.
Most of the frustration is caused because people are enthusiastic starting with AVR/µC but are not aware of the system limitations compared to a PC or are not familiar with the C language. Learning C on a PC is much more comfortable.

Quote:
"Doubles" are the same as float, 32 bit IEEE.
That's the only bit where avr-gcc does not comply to the C standard.

For avr-g++ there are more limitations because of the really tiny hardware.

Quote:
In time I expect that the avr-gcc community will fix it up according to their personal wisdom,
It's not about "wisdom", it's about the number of guys that are willing to contribute to avr-gcc. That number is close to zero.

skeeve wrote:
To meet ANSI and IEEE standards, eight bytes are not necessary. We could use seven or even six bytes. Also, we could use base 256.
Just explain the "we" part, please.

You can propose anything. It's waste of time as long as no one is willing to add this to GCC.

The more unconventional the implementation is, the less likely you will see it. You know very well that there are *not* dozens of developers enthusiastic to contribute to avr-gcc...

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you, that is what I needed to know. Since he recently learned how to multiply and divide multiple digit numbers by hand, positional number systems, bases, etc. I think understanding that a computer with a limited work length will be very natural - arithmetic is done "base 256", laboriously. He can relate to that! He will also actually see and so understand how adding a small number to a big number gets lost. It will be very intuitive. We'll see how it goes. I obviously have a different perspective - I think its a crime how nobody is growing up to understand how computers work any more. Its especially ironic that most software engineers don't know how computers work! They just know their objects. Anyway, no offense intended to anyone, but that's how I see it. Thank you for the information.
--Ray

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

FYI, 64-bit double support is upstream and will be released with v10:

 

https://gcc.gnu.org/gcc-10/chang...

 

According changes needed for avr-libc are not upstream yet, but there are development snapshots: (the v10 ones):

 

https://sourceforge.net/projects...

 

The default for float/double/long double is 32/32/64.  For 64-bit double you need -mdouble=64.

 

You'll find some performance data in the graphics attached to https://www.mikrocontroller.net/... with labels "f7" resp. "f7_t".  Other labels refer to different IEEE implementations.

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lol -- a response with a useful purpose and also a Necromancy Award candidate.

 

I'd guess that "double" has been a topic in GCCland (AVr province) for some time.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ya, it's in AVR land but very dilute.  And I didn't intend to dilute it even more.

 

As the original is from 2002, and some discussion unfolded 2012, I assumed it would be in order to add some pointer which is not completely worthless (hope so).

avrfreaks does not support Opera. Profile inactive.

Pages