Support for 32-bit hardware platforms?

[JakubSosnovec]

I understand that officially, iceoryx only supports 64-bit hardware platforms. I know about the requirement that the platform supports lock-free 64-bit atomics.

• Is there any other strong reason why 32-bit platforms cannot be supported?
• Can you expand on the lock-free 64-bit atomics requirement? Why is it needed?

In our experiments, we commented out the 64-bit atomics check (https://github.com/eclipse-iceoryx/iceoryx/blob/master/iceoryx_hoofs/source/concurrent/loffli.cpp#L32) and we then we can actually build for 32-bit platforms. Furthermore, iceoryx seems to run correctly, as far as our testing goes (which isnt too far at all).

However, we get a ton of compiler warnings. However, these are just two types:

• Wconversion: when using 64-bit values to index into pointers and arrays, etc. It seems that all integer-templated types in iceoryx_hoofs use uint64_t for the template parameter, for example the iox::cxx::vector class declaration looks as: template <typename T, uint64_t Capacity> class vector. Furthermore, for example even the index operator of iox::cxx::vector takes a uint64_t parameter. But, in C++, AFAIK, indices are either std::size_t or std::ptrdiff_t, which are 32-bit integers on 32-bit integers platforms. The compiler doesnt like that.
• Wcast-align: it also complains about a lof of code in iox::cxx::variant, somehow it cannot recognize that the reinterpret_casts there are fine because of the alignas specifier. Not sure why it works fine on 64-bit platforms and doesnt on 32-bit platforms, actually.

Of course, we could just disable these warnings and go about our day. But I was wondering whether there are any concerns, ideas or comments about this?

For context, we are using gcc 10.2 for the compilation. And iceoryx release v2.0.2.

[elfenpiff]

@JakubSosnovec

Is there any other strong reason why 32-bit platforms cannot be supported?

Actually there is no other strong reason and 2 years ago we ported iceoryx to 32-bit and it was running with the atomic restriction. But we did not pursued it any further since we had no use case at that time.

Can you expand on the lock-free 64-bit atomics requirement? Why is it needed?

We require lock-free algorithms to ensure a thread-safe access to the shared-memory constructs. We decided against mutexs since it is possible that an application dies while holding a lock and a mutex can only be unlocked by the owner. Such a case would then lead to a total deadlock of the whole system.

Usually we use 64-bit in a way that 32-bit are some kind of index and the remaining 32-bit are an aba counter. But in most cases we could reduce the index and aba size. The lock-free algorithms are then maybe less safe but for a first shot it would be fine.
Another approach would be to deactivate the enforcement of lock-free algorithms on 32-bit. When this would be fine for you we could go that route.

Wconversion

You are right and we decided against them. The main reason is serialization and a memory layout which is platform independent. Just think of the problem one encounters when serializing a size_t from 32-bit to 64-bit a vice versa.
This gets even worse. size_t is not necessarily 64-bit in size on a 64-bit system, it is defined as a number which can index the whole memory and on a 64-bit system with 1gb of memory 32-bit is enough.
So we stick with the types with a specific size. Additionally, when certifying the code we have to follow rules which require us to only use sized types.

As solution I would introduce a little helper in iceoryx_platform which performs a conditional static_cast whenever the index size does not fit. Then the warning should go away.

Wcast-align

This is weird and has to be investigated further. I think if we want to make 32-bit fly we require a CI target for this. As soon as I have time I would dig into it but only if you are not digging faster ;)

[elBoberido]

@JakubSosnovec hahaha, that was exactly the reason we didn't use it in the first place and also why we implemented uninitialized_array.

Could you check if this code would give you the warning?

struct alignas(T...) storage_t
{
    uint8_t data[algorithm::maxVal(sizeof(T)...)];
};

storage_t m_storage;

A reinterpret_cast<T&>(m_storage) should then work without a warning

[JakubSosnovec]

@elBoberido Yes, that works

[elfenpiff]

@FerdinandSpitzschnueffler I brought you here into the loop since the uninitialized_array is your child. We could try the approach that @elBoberido drafted for the uninitialized array to get rid of the cast align strict warning.

[FerdinandSpitzschnueffler]

@JakubSosnovec @elfenpiff I implemented @elBoberido's approach in #1774. Maybe you can check if there are still cast align warnings.

[elBoberido]

@FerdinandSpitzschnueffler there are still some warnings and I proposed a solution in the PR. They are not related to the UninitializedArray changes but the call_at_index structs in the variant code. Nothing is broken but the compiler cannot proof if and therefore there is the warning.

cc @JakubSosnovec @elfenpiff

[JakubSosnovec]

@elBoberido @elfenpiff So, I managed to persuade the compiler to stop producing warnings with -Wcast-align=strict for cxx::variant. Here is the monstrosity that I came up with: 9e8dc3a

Do you guys want it? I think it makes the code a bit more correct, but at the cost of more template magic...

[JakubSosnovec]

Btw, there is still quite a lot of warnings produced with-Wcast-align=strict, especially from unitialized_array.