CPU-specific SharedCLibrary tweaks/extending clib static data
Jeffrey Lee (213) 6048 posts |
I recently spotted that the file s.longlong in the SharedCLibrary sources has the ability to make use of CLZ, UMULL, etc. instructions if the host supports them. However the code to detect the CPU architecture at runtime is disabled, because storing the cached value in static workspace “can’t be done as a retrofit to old versions”. I’ve fixed the code so that ROM-based versions of the module can select the right routine at compile time, but what needs doing to get the CPU detection routine working? I would have thought it would just be a case of “claiming” one of the unused bytes in kernel.s.k_data? Or are there issues with things like clashes between ROL & ROOL allocations? Or issues with softloading different versions? |
Ben Avison (25) 445 posts |
That code’s my fault, it didn’t exist in the closed-source version. I’m afraid I can’t remember the reasoning, it seems most likely I’d just hit the stubs size incompatibility issue that happens when you simply add a new static variable rather than replacing one of the unused ones, and had forgotten about the option of replacing an unused variable? I suspect the variable only really needs to be a byte, not a word. One small comment I’d make about your changes is that CLZ was introduced in architecture 5, not 5T. The latest ARM ARM is lying (it doesn’t document vanilla v5 at all, but earlier ARM ARMs reveal the truth). This should make your switches a little simpler. |
Jeffrey Lee (213) 6048 posts |
Ah, yes, I thought I remembered reading about something like that, but forgot to check the ARMv5 ARM to see what that said. I’ll have a go at updating the code to use one of the spare bytes and see if anything bad happens. |