Generating FFP values at compile time
I'm working with FFP format floating point numbers, using C++ Bartman's GCC environment, cross compiling from Windows.
I have a type, real, that's really just a LONGwith a bunch of overloaded operators to make it appear almost like an inbuilt type. Everything works, except initialising these objects is awkward. I can't just go: Code:
real pi = 3.14159; Code:
real pi = a2r("3.14159"); At the moment I have a bunch of #defined constants: Code:
#define r_pi 0xC90FDB42UL Does anyone have any smarter ideas? |
Well, for Os 3.1.4, we had kinna the reverse problem, namely to let SAS/C accept IEEE single precision constants. The solution there, albeit hacky, was to have a (self-written) preprocessor (not the standard C preprocessor) which took these constants, and converted them to references (i.e. __3_14159), and then later in the build stage, C was compiled to assembler (not object code), and a second script then converted those constants by suitable immediate hex values.
It was really a sort of abuse of the SAS/C compiler chain, and an external "hack" that abused that chain. |
I've done something similar.
I wrote a wrapper class around the FFP library. Then pulled some helper functions from elsewhere for conversion from and to ieee floats. I also added some trig/math code as needed. For my implementation you can declare an FFP with the following helper function: ffloat value = ffloat_from_ieee(1.2345f); It's relatively fast but it's still better to do this all upfront so it's only slow for the initial setup. You can also create ffloat's from ints: ffloat value = ffloat(1) / ffloat(100); // 0.01 I've shared my class over at: https://github.com/rjobling/ffloat |
Quote:
Trouble mostly is that I'd have to write a preprocessor to run under Windows, and I've never done any Windows development before. |
Quote:
One of the problems I have is the static initialisation of flexible array members with that kind of approach ( ffloat_from_ieee or a2f = ffloat from char * ). I'm not sure if it's my code to blame, or a gcc bug. Maybe it would be worthwhile me testing with your approach as well as mine. |
I don't know what you mean by "static initialization of flexible array members"?
Can you show me an example of what you're doing? |
|
Cool! I hadn't considered trying to get it all to happen at compile time. But that's pretty awesome that it can be made to work.
|
Quote:
First, if it's command line, it's not any different. Just use gcc, and your standard main() to collect command line arguments. Second, you can always use vamos and write an amiga binary. This is what I did as "pre-processor", but it was supposed to operate in an all-amiga environment anyhow. |
Quote:
I think I'll look for something else for the text replacement part, maybe I can make do with a sed script. |
Quote:
Code:
#include "../real_constants.h" Code:
static VertexComponentData yVertexComponentData = { |
Quote:
|
Quote:
How will that approach work with cross compilation? I'll obviously not be able to use my existing a2r function. |
Quote:
You have to call the ffpfieee() function and instead of strings supply c++ floats. |
Quote:
But, my question was, how will that work with the cross compilation environment I outlined in post #1. The constexpr code needs to be executed, right? But my compiler is running on windows but generating 68000 Amiga code. How can the code be executed at compile time? Edit: I'm learning more about this new constexpr thing, and I'm now seeing that it's not code that is executed, it just allows for really complicated expressions to be evaluated, with a whole bunch of restrictions that change every few years. It will be interesting to see if I can parse a string with it. |
The site where you see the code is using a cross-compiler toolchain. So it works in cross-compiler for sure.
But why would you want strings? Code:
int a[] = { Code:
int a[] = { |
Quote:
|
the function ffpfieee is "ffp from ieee"
Check the hex representation here https://godbolt.org/z/fWbzjTbff |
Quote:
|
Quote:
|
All times are GMT +2. The time now is 13:58. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.