Author |
Topic: Sortlib queries (Read 504 times) |
|
mavison
New Member
member is offline
Posts: 27
|
 |
Re: Sortlib queries
« Reply #4 on: Feb 21st, 2017, 3:29pm » |
|
No need to apologise - BB4W & BBCSDL are both great achievements!
I think if smode=2 is the only one that works as documented, all others that do not should be rejected. I believe in safe coding!
I am used to using ARM code under BBC Basic under RISC OS - just ask if you want anything checking.
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Sortlib queries
« Reply #5 on: Feb 21st, 2017, 4:18pm » |
|
on Feb 21st, 2017, 3:29pm, mavison wrote:| I am used to using ARM code under BBC Basic under RISC OS - just ask if you want anything checking. |
|
Thank you, although I can't see myself attempting to write ARM assembler code even with some hand-holding! What I ended up doing for SORTLIB, as I may have mentioned before, is translating the x86 assembler code to C and then compiling that for ARM as a 'binary blob', which is incorporated in the library as hex data statements.
I encountered various challenges which will sound silly to anybody familiar with the ARM CPU. One of those was that the compiler generated 16-bit 'thumb' code and I was initially puzzled as to why it crashed. Of course all I had to do was add 1 to the value returned by FN_sortinit(), the LSB of the called address being the flag that indicates that it is thumb rather than 32-bit ARM code. Obvious when you know!
As an 'outsider' as far as the ARM is concerned I find it interesting that when I compile BBCSDL for Android it always generates thumb code, presumably because the saving in code size outweighs any performance hit from the even-more-reduced instruction set! It makes me wonder whether a thumb-like 16-bit instruction set would have been a better choice from the very start, or is it only recent advances in CPU architecture that have made it competitive?
Are there any situations in which one would choose to compile to 32-bit ARM code these days?
Richard.
|
|
Logged
|
|
|
|
mavison
New Member
member is offline
Posts: 27
|
|
Re: Sortlib queries
« Reply #6 on: Feb 21st, 2017, 5:31pm » |
|
I am the wrong person to ask! I have only written 'normal' 32 bit ARM code (as used in RISC OS), never Thumb code. I believe Thumb is becomming more popular because it is now being used in memory-limited environments. But there are probably more complex reasons.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Sortlib queries
« Reply #7 on: Feb 21st, 2017, 5:58pm » |
|
on Feb 21st, 2017, 3:29pm, mavison wrote:| I think if smode=2 is the only one that works as documented, all others that do not should be rejected. |
|
OK, but I can't see how to achieve it. The smode parameter is only relevant when the array being sorted is a string array, but that isn't known when FN_sortinit() is called. Only later when the machine-code sort routine is CALLed does it become evident that a string-sort is involved, but a BASIC error cannot be raised at that point.
If that analysis is correct, all I can reasonably offer is to reject values other than 0 and 2, because an smode value of zero must be allowed when only a numeric sort is being performed. That doesn't fulfil your request, and it will also reject a 'valid' set of parameters (e.g. smode being set to 1 and a numeric sort being performed).
Am I missing something?
Richard.
|
|
Logged
|
|
|
|
mavison
New Member
member is offline
Posts: 27
|
|
Re: Sortlib queries
« Reply #8 on: Feb 22nd, 2017, 4:03pm » |
|
Hmmm yes - I see your problem. Other values of smode can be valid if strings not sorted. If it cannot be trapped easily, then in the absence of updated SDL docs (and I hope someone helps you with those) perhaps the only way is to put a big REMark in the sortlib itself. Certainly I looked in there for any clues why I was having problems, and perhaps others might too.
[The sort module I wrote for RISC OS to do very similar functions allows asc/desc & case/sign ignores to be set for each array, which is why I did not immediately see there was a problem with my request!]
Thanks
Martin
|
|
Logged
|
|
|
|
|
