[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Pexec() patch in FireTOS

Hi Lonny,

I think nobody can tell if this patch will make it work, but at least it will take you a good deal forward.

The background is that the Pure C libs use a feature/quirk in the 68k architecture to speed up the code a bit.

They avoid a slow (on 68000 only) lsl.w #8,xxx (a multiplication by 256) by pushing a byte to the stack and fetching it back as a word.

The m68k requires a word-aligned stack. Motorola engineers decided to implement a 'self healing stack' feature that silently extends a byte pushed to the stack into a word to keep the alignment. Which I found always ugly btw, since it makes the - otherwise pretty and straightforward - instruction set unorthogonal, making the A7 register behave differently than any other address register - in my opinion it should just crash in such case.

(Ab-)using that feature, you can pop this extended byte back as a word, effectively resulting in a left shift by 8 bits. On mc68000 that lacks the barrel shifter later chips had (which made shift execution times independend of shift size), this is much faster than the equivalent (clean and slow) lsl.w instruction.

Coldfires can deal with an unaligned stack (it just makes them a little slower), so Freescale removed that 'self healing stack' feature from the instruction set. If you push a byte and pop a word on Coldfires, you get the low byte of whatever was on the next higher stack address in the high byte of the popped word, but even worse, you damage the next higher stack contents resulting in a crash sooner or later.

Bad decisions always get punished. It just takes a while, sometimes


P.S.: this is something the cf68klib (the m68k emulation library used in FireTOS) cannot catch and fix on the fly as it does for other incompatible m68k code. The cf68klib relies on exceptions fired by incompatible instructions. As the instruction stream of Pure C's memset() implementation is perfectly valid code on Coldfire as well (it just yields different results), there is no exception to catch. Thus, FireTOS intercepts Pexec() and explicitly scans for the specific byte pattern of Pure C's memset() library routine to apply a patch. This fixes the issue for Pure C compiled programs, but other code (that has a different byte pattern but also uses this 'trick') will still fail.

Am 26.08.2015 um 02:32 schrieb Lonny Pursell:
I was looking at this:

After some study I see that this patch is searching for the code that makes
up memset() in the PureC library. Inside the LDG library is a call to
memset() which in turn makes all of codecs built against the LDG library
fail on the firebee. So is is enough to replace the memset() call with a
patch one to get my codecs working on the firebee?