Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-25 Thread Rony G. Flatscher
Just for the record: Rick and Erich have updated the code and improved the speed considerably, which is really great! ---rony On 19.04.2019 17:01, Moritz Hoffmann wrote: > Hi, > looking at ooRexx's implemetation of x2c I find the original code much easier > to understand and to > reason

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Moritz Hoffmann
Hi, looking at ooRexx's implemetation of x2c I find the original code much easier to understand and to reason about. Instead of hand-tuning an implementation I'd like to know why the native implementation is slower than your approach. I'd suspect it's because it's using strchr to validate each

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher
Double-checked the test hex strings and their positions of illegal whitespace chars, here the native routine with the corrected position: int64_t hex2char(RexxCallContext *rcc, CSTRING hexData, size_t len, char *data) { // check for trailing whitespace char

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher
On 19.04.2019 15:55, Rony G. Flatscher wrote: > On 19.04.2019 13:09, Rick McGuire wrote: ... cut ... Sorry, the following error message is  correct, the position 6 is correct (had changed the hex string): > > * the hexadecimal string "Ab  0 0  ff  00  ff  00  ff  12" has an illegal >

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher
On 19.04.2019 13:09, Rick McGuire wrote: > Well, you're missing all of the logic that allows for blanks at the > boundaries and you're also > assuming that you have an even number of digits to convert. If you remove all > of the things that > x2c() has to account for, then yes, you can do a

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rick McGuire
Well, you're missing all of the logic that allows for blanks at the boundaries and you're also assuming that you have an even number of digits to convert. If you remove all of the things that x2c() has to account for, then yes, you can do a faster conversion. Rick On Fri, Apr 19, 2019 at 6:51 AM

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-19 Thread Rony G. Flatscher
Thank you all for your feedback to my quite "dirty" ;) posting! As Mike pointed out 'a'-'z' were not honored, but also blanks in between pairs of hex digits, which Rexx allows for. Rewriting the algorithm a little bit it runs even faster (up to 4.5 times compared to x2c()): /* A Rexx hex

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-18 Thread Mark L. Gaubatz via Oorexx-devel
: Re: [Oorexx-devel] An alternative algorithm for x2c() Rony: Too many comparisons are being done from a performance perspective; a minimal comparison for validation and no comparison for translation is the fastest. Actual translation should be done with a pair of 256-byte arrays for s

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-18 Thread Mark L. Gaubatz via Oorexx-devel
Rony: Too many comparisons are being done from a performance perspective; a minimal comparison for validation and no comparison for translation is the fastest. Actual translation should be done with a pair of 256-byte arrays for speed AND portability across character sets. Speed varies

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-18 Thread Mike Cowlishaw
case 'A': tmp=10; break; case 'B': tmp=11; break; case 'C': tmp=12; break; case 'D': tmp=13; break; case 'E': tmp=14; break; case 'F': tmp=15; break; Also need to add cases 'a' through 'f'? ___

Re: [Oorexx-devel] An alternative algorithm for x2c()

2019-04-18 Thread Mike Cowlishaw
Not sure if it would be any faster, but maybe neater to simplify some of the below along the lines of: case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': case '8': case '9': tmp=hexData[i-1]-'0'; break; (I'd also make the increments of i