On 6/2/20 1:07 PM, John Paul Adrian Glaubitz wrote:
Hi!
On 6/2/20 1:04 PM, Geert Uytterhoeven wrote:
What do you mean with the sentence "when arch/ppc/ was still king"?
Ah, Bartl copied that from my email ;-)
There used to be APUS support under arch/ppc/. Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\ architecture port under arch/powerpc/, and the old ones were dropped. APUS was never converted, and thus dropped.
Ah, yes. Similar to the merge with x86.
Does that mean - in the case we would re-add APUS support in the future, that these particular changes would not be necessary?
They would still be necessary, as PowerPC doesn't grok m68k instructions. Alternatively, we could just drop the m68k inline asm, and retain the C version instead? I have no idea how big of a difference that would make on m68k, using a more modern compiler than when the code was written originally.
Hmm, no idea. I would keep the assembly for the time being. This was just a question out of curiosity. We could still consider such a change if someone should consider working on APUS support again.
Note that all of this is used only for cursor handling, which I doubt is actually used by any user space application. The only exception is the DIVUL() macro, which is used once during initialization, thus also not performance critical.
I see, thanks.
Since the code in question is not performance critical it indeed seems to be good idea to use C version. However it still would need be tested on the hardware (or emulator at least) so for the time being I think that we should just add another FIXME comment instead of doing real code changes..
Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics