🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Back to General and Gameplay Programming

Handling "float" in in generic memory (blob)

Julian Watzinger · 2021-05-27T18:40:04

Hello, so for my bytecode/interpreted language, I have support for primitive types - mostly byte, int and float. For a while I've been treating int and float separately - there are multiple operations, like loading from and storing to a local variable: case OpCodes::LoadInt: { const auto offset = stream.ReadData<LocalOffset>(); const auto value = m_stack.GetValue<int>(state.pFrame, offset); m_stack.Push(value); break; } case OpCodes::LoadFloat: { const auto offset = stream.ReadData<LocalOffset>(); const auto value = m_stack.GetValue<float>(state.pFrame, offset); m_stack.Push(value); break; } case OpCodes::StoreInt: { const auto offset = stream.ReadData<LocalOffset>(); auto& ref = m_stack.GetRef<int>(state.pFrame, offset); ref = m_stack.Pop<int>(); break; } case OpCodes::StoreFloat: { const auto offset = stream.ReadData<LocalOffset>(); auto& ref = m_stack.GetRef<float>(state.pFrame, offset); ref = m_stack.Pop<float>(); break; } The reason that I originally that it that way, is that I saw a lot of languages do it that way (Java for example), and I didn't think much of it. Now that my language is pretty evolved, I'm trying to converse space in the “OpCodes", so that they can stay 8 bit (I'm currently using 222 out of 255). And that got me thinking - is there actually any benefit for treating “float” explicitely in a situation like the above? I'm thinking about changing the instructions above to “LoadWord" and “StoreWord”, which would handle word-sized variable, properly via ind or uint, instead of separate int/float. I'm just not sure if its a good idea. I know from testing that in general reinterpret_casting a the content of a float to an int works and preserves certain aspects/operations (equality/ordering). But on the other hand, the c++-compiler always generates specific instructions/registers (XMM) for dealing with floating-point types. So is it actually advantageous to always treat float-data as “float”, or is the generated floating-point-assembly just better when dealing with large-scale floating point operations (like a full functions of float-operations following each other; which is not the case in my bytecode)? Hope my question/concern makes any sense, perhaps from somebody who knows a bit more about the inner workins of CPUs and/or IEEE-standards and what not.

General and Gameplay Programming Programming

Started by Juliean May 22, 2021 12:53 PM

20 comments, last by Juliean 3 years, 1 month ago

Juliean

7,352

Author

May 27, 2021 06:40 PM

SyncViews said:
Well all of this was talking about debug. In release if it doesn't inline smaller templates and other wrapper functions something is up, normally I managed to get it to do so and once inlined it ends up almost the same as if the logic was their directly.

Yeah, I'm also still mostly talking about debug. In release, absolutely true, it should inline pretty much every small function. Unfortunately without link-time generation it doesn't seem to be able to inline functions where the definition is hidden in a cpp-file (which actually makes sense), whIch i think you were talking about:

SyncViews said:
So using macros should just be to potentially make a debug build more usable if don't want to mix flags on compilation units or need some header-only stuff to be fast.

I mean, thats a different topic on its own. I should be able to manually inline verything that matters, and otherwise rely on LTO.