Sorry to keep causing problems like this, but I wanted to ensure the unit tests for l_bsearch and l_qsort now run for the 8080 cpu now that the code is in place as a result of https://github.com/z88dk/z88dk/pull/2103 .
I didn't realise the test that was added has a specific "#ifndef __8080__" filtering it out. So I've enabled that test to run on the 8080 clib now as well: https://github.com/z88dk/z88dk/pull/2106
Testing l_bsearch for 8080
Re: Testing l_bsearch for 8080
Did you want to have qsort enabled too?
I think that the test is still turned off for 8080 (current to this post).
I think that the test is still turned off for 8080 (current to this post).
-
- Member
- Posts: 80
- Joined: Sat Feb 06, 2021 2:32 pm
Re: Testing l_bsearch for 8080
It's a little bit of a complicated situation there. As I understand it:
- In the classic clib, originally only l_bsearch and l_qsort existed. These are non standard z88dk specific extensions to stdlib. The comparison function pointers they take are expected to return a signed char rather than an int and there isn't an element size parameter as a size of 2 bytes is assumed. But due to the way signed chars are returned by z88dk in HL with H=0, if a function pointer that returns an int value of 1 (0001h), 0 (0000h) or -1 (FFFFh) is used it will still work as expected.
-Afterward, a standard clib implementation of qsort has been created (distinct from l_qsort), but a standard implementation of bsearch doesn't exist in z88dk's classic lib. Newlib has both qsort and bsearch but I only use classic myself as newlib doesn't do file io at present. l_bsearch/l_qsort are sufficient for my needs also.
-The "bsearch" test actually tests *both* l_bsearch and l_qsort. The "qsort" tests test the later, standard version of qsort
My recent change was only to make l_bsearch and l_qsort work on 8080, hence why that's the only test I changed.
- In the classic clib, originally only l_bsearch and l_qsort existed. These are non standard z88dk specific extensions to stdlib. The comparison function pointers they take are expected to return a signed char rather than an int and there isn't an element size parameter as a size of 2 bytes is assumed. But due to the way signed chars are returned by z88dk in HL with H=0, if a function pointer that returns an int value of 1 (0001h), 0 (0000h) or -1 (FFFFh) is used it will still work as expected.
-Afterward, a standard clib implementation of qsort has been created (distinct from l_qsort), but a standard implementation of bsearch doesn't exist in z88dk's classic lib. Newlib has both qsort and bsearch but I only use classic myself as newlib doesn't do file io at present. l_bsearch/l_qsort are sufficient for my needs also.
-The "bsearch" test actually tests *both* l_bsearch and l_qsort. The "qsort" tests test the later, standard version of qsort
My recent change was only to make l_bsearch and l_qsort work on 8080, hence why that's the only test I changed.
-
- Member
- Posts: 80
- Joined: Sat Feb 06, 2021 2:32 pm
Re: Testing l_bsearch for 8080
Frankly, I think it might be useful if classic's qsort separate implemention could be dispensed with and newlib's qsort+bsearch made available from the classic clib. With l_qsort and l_bsearch staying as they are that is. I don't know if newlib is compatible with non z80 processors though.
Re: Testing l_bsearch for 8080
No sorry, newlib isn't generally INTEL compatible. Though there are exceptions to prove the rule.I don't know if newlib is compatible with non z80 processors though.
The RC2014-8085 target stitches both newlib and classic crt0 code to produce something that will run on 8085, but exists mainly in newlib. The startup crt0 code has to reach across to the directory structure to classic lib to set up various pieces during startup.
Going to be someone's fun job to rewrite newlib functions for all the machine types in the same inheritance style as the sccz80 l_ functions.
![:O](./images/smilies/yikes.png)
-
- Member
- Posts: 80
- Joined: Sat Feb 06, 2021 2:32 pm
Re: Testing l_bsearch for 8080
So it seemsGoing to be someone's fun job to rewrite newlib functions for all the machine types in the same inheritance style as the sccz80 l_ functions.
![=D](./images/smilies/big_smile.png)
I'd like to help out with that. Although I'm not super experienced with z80 assembly though as you've seen
![:)](./images/smilies/smile.png)
For my purposes it doesn't matter too much how fast what I write is as long as it gives the proper results at the end.
Re: Testing l_bsearch for 8080
There's been a "thought" for some years, afaik, to lift newlib out of the cellar of _DEVELOPMENT. But it might be more like moving classic in parts into newlib at the same time, as was done with the sccz80 l_ functions, and try to unify each asm function to one api for all machines. Basically a merging of the two libraries is foreseen.pjshumphreys wrote: ↑Sat Oct 22, 2022 1:11 pmI'd like to help out with that.Going to be someone's fun job to rewrite newlib functions for all the machine types in the same inheritance style as the sccz80 l_ functions.
Would be good to get some qualified feedback on this as though...
There's always the genesis issue #4 where you can leave a comment and kick off new discussion.
Or on the #1931 issue, where there's been more action recently.
For something specific to do, the #1930 issue has some guidance on what needs done. From earlier this year.
-
- Member
- Posts: 80
- Joined: Sat Feb 06, 2021 2:32 pm
Re: Testing l_bsearch for 8080
Major source reorganisations are a bit beyond my own sphere of interest. As a user of z88dk I'm interested in expanded support for existing or new functionality. I can appreciate a more organised source tree would indirectly help with that though.
My main focus is on my long term personal project (https://github.com/pjshumphreys/querycsv). Among the targets I'm producing are a zx spectrum build (with 3 of its major disk systems) and a cpm/msx build (that uses MSXDOS memory mappers and/or msxdos2 disk routines if they are available but will otherwise work more slowly on any z80 based cp/m). I'm using z88dk to compile for these 2 targets but I'm using a whole bunch of other C compilers for the others.
This project of mine exercises just about every piece of functionality in the c standard library, and has shims for the parts that are unavailable on certain targets.
If when I try to compile my project something doesn't exist or is broken, that's where my interest lies. I've recently been investigating creating a 8080 cp/m build as intermediate step to supporting the Atari Portfolio, which although has an 8086 it only has around 100KB of ram available so is more like cp/m in use than msdos. Making my cp/m build 8080 compatible is also a potential future direction.
My main focus is on my long term personal project (https://github.com/pjshumphreys/querycsv). Among the targets I'm producing are a zx spectrum build (with 3 of its major disk systems) and a cpm/msx build (that uses MSXDOS memory mappers and/or msxdos2 disk routines if they are available but will otherwise work more slowly on any z80 based cp/m). I'm using z88dk to compile for these 2 targets but I'm using a whole bunch of other C compilers for the others.
This project of mine exercises just about every piece of functionality in the c standard library, and has shims for the parts that are unavailable on certain targets.
If when I try to compile my project something doesn't exist or is broken, that's where my interest lies. I've recently been investigating creating a 8080 cp/m build as intermediate step to supporting the Atari Portfolio, which although has an 8086 it only has around 100KB of ram available so is more like cp/m in use than msdos. Making my cp/m build 8080 compatible is also a potential future direction.
-
- Member
- Posts: 80
- Joined: Sat Feb 06, 2021 2:32 pm
Re: Testing l_bsearch for 8080
I've just gone into the example sub directory and run `make`. Everything seems to build without any errors being thrown. I'm not sure what's broken with the examples that https://github.com/z88dk/z88dk/issues/1930 seems to be referring to?
If something has worked up to now for end users will it not be continuing to work? Is it the case that new examples need to be written to demonstrate new functionality?
If something has worked up to now for end users will it not be continuing to work? Is it the case that new examples need to be written to demonstrate new functionality?