>And if hal_u32_t was mapped into an S64 (as I am proposing) then >nothing at all would need to change in this code.
I am fully aware data types can change with platforms but in this case, this part time programmer knows what platform he is compiling for. If the hal_u32_t Word in this instance is changed to an S64, how can you guarantee that the S64 is mapped back to the hal_u32_t when it's written back to the Ethercat drive that has an externally defined register size? Rod Webster *1300 896 832* +61 435 765 611 Vehicle Modifications Network www.vehiclemods.net.au On Wed, 11 Oct 2023 at 21:52, andy pugh <[email protected]> wrote: > On Wed, 11 Oct 2023 at 12:08, John Allwine <[email protected]> wrote: > > > > Seems like there could be a significant performance hit for 32 bit > architectures. We don’t directly use LinuxCNC, but EMCApplication is a > shallow fork of LinuxCNC that will occasionally pull from upstream. We use > EMCApplication on the BeagleBone Black, which is a 32 bit architecture and > is already a bit strained performance-wise. > > That's unfortunate. Debian is no longer shipping 32-bit installers and > LinuxCNC only supports Buster, Bullseye and Bookworm on x86 and arm64 > at the moment. > > I assume that this also means that you are not using the new 64-bit HAL > pins? > > A compile-time switch to force everything (_including_ 64-bit HAL > pins?) to 32 bits should be possible. > > -- > atp > "A motorcycle is a bicycle with a pandemonium attachment and is > designed for the especial use of mechanical geniuses, daredevils and > lunatics." > — George Fitch, Atlanta Constitution Newspaper, 1912 > > > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
