Re: [StrongED] TaskWindow in StrongEd 4.70a6

[Fred Graute <fjgraute@xxxxxxxxx>]

In message <mpro.nei9ud00b3auv00l4.pittdj@xxxxxxxxxxxx>
          David Pitt <pittdj@xxxxxxxxxxxx> wrote:

> Fred Graute, on 3 Nov, wrote:
>
> > In message <c6ede26054.pittdj+@xxxxxxxxxxx>
> >           David Pitt <pittdj@xxxxxxxxxxxx> wrote:

[SE 4.70a6 apparently being fine without CallASWI]

> There is something not right here. 4.70a6 seems to be just fine on both
> OS4.02 and OS 4.39 without CallASWI.

SE is calling XOS_HeapSort so it doesn't error but no sorting is done.
That said, OS4.02 seemed to be happily sorting stuff even though there's
no OS_HeapSort32. This still baffles me!

> > Had a peruse through the Select change logs and it turns out that support
> > for OS_HeapSort32 has been added on 20 Aug 2004 (some time after Select
> > 3i4). Loading CallASWI > 0.02 means there's 2 implementations of that SWI
> > which may explain the abort. Why this also fixes RO4.02 is beyond me ATM.
>
> As far as I can see neither OS4.02 nor OS4.39 offer SWI OS_HeapSort32, they
> are the same in this respect. OS4.39 is Select 3i4, so OS_HeapSort32 is
> probably added with the 32bit ROL OS, it is present in the A9home's OS4.42.

For OS4.39 have a look in the OSSWIs module, this is where OS_HeapSort32
is implemented in the RO6 preview. You'll need to look for the function
signature as the module doesn't have a regular SWI table.

> The CallASWI rmensure in 4.70a6 needs a tweak, CallASWI should not be called
> on OS4.42. I think that is the reason that ROL introduced a dummy CallASWI
> module, which would need to be flagged as 32bit, to side-step problems
> caused by applications wrongly calling the module.
>
> http://www.riscos.com/support/developers/riscos6/legacy/dummymodules.html

Thanks for the reminder. It's a bit strange though they didn't use a
higher version number just to be absolutely safe.

> > It might be easier to reinstate the internal HeapSort than trying to find
> > which CallASWI to use on what version of the OS, which looks to be a
> > fiddly job now.
>
> I get the feeling that answer might be close to hand, it would be a shame to
> bin a lot of work five minutes too soon.

Well the good news is that I've found the culprit, it's the comparison
routine for Kill All. As addresses are unsigned and OS_HeapSort uses
signed branches we need to tweak the PSR flags so things work correctly.

This means using TEQP on 26-bit but the processor mode wasn't taken into
account, it was forced to USR mode. This was fine with the internal
HeapSort as it called the comparison routine in USR mode anyway. But
OS_HeapSort calls the comparison routine in SVC mode and dropping into
USR mode caused things to go bang.

I've come up with a different way of tweaking the PSR flags that doesn't
need TEQP and is 32/26 bit neutral and now Kill All works correctly on
26-bit RISC OS.

Now to find out which versions of RISC OS have OS_HeapSort32 available
and load CallASWI 0.03 on versions that don't support it.

Cheers,
Fred.

-- 
StrongED Developer
http://www.stronged.iconbar.com/

--
To unsubscribe send a mail to StrongED+unsubscribe@xxxxxxxxxxxxxx
List archives at http://www.Torrens.org.uk/RO/StrongED/index.html