New jpeg.library implementation based on libjpeg-turbo with Altivec acceleration is nearly complete. I just wasted the last 3 days on an ISI crash/hangs, slowly rebooting the X1000 a hundred times, caused by a brainfuck in memset(). It was overrunning 1 byte destroying an error handling function pointer inside libjpeg.
Anyway, FIXED last night! Now all that remains is to implement setjmp, the last hurdle of stdlib, and we are good for beta-testing :)
The reader already works, just need to test the writer.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
I just wasted the last 3 days on an ISI crash/hangs, slowly rebooting the X1000 a hundred times, caused by a brainfuck in memset(). It was overrunning 1 byte destroying an error handling function pointer inside libjpeg.
Error handlers using setjmp tested and working. Jpeg writer also working.
Had to implement setjmp/longjmp from scratch in assembly, with some help from google, since I have no stdlib. All required parts of stdlib are reimplemented from scratch.
Now testing all the different scenarios using the jpeg_library dev examples. Hooks are untested and apparently doesn't quite work...
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Error handlers using setjmp tested and working. Jpeg writer also working.
Had to implement setjmp/longjmp from scratch in assembly, with some help from google, since I have no stdlib. All required parts of stdlib are reimplemented from scratch.
Why on earth didn't you use newlib? That's what it for?
Quote:
Now testing all the different scenarios using the jpeg_library dev examples. Hooks are untested and apparently doesn't quite work...
If they are amiga hooks make sure you use CallHookPkt() and make sure the argument order is correct.
Had to implement setjmp/longjmp from scratch in assembly, with some help from google, since I have no stdlib.
This sounds like a strange thing to do. I really wonder what stopped you from using newlib, as Broadblues has suggested. In 2015 and in assembly????? I really want to hear the story.
Why on earth didn't you use newlib? That's what it for?
SDK:newlib/include/setjmp.h says "stubs for future use."; which I would assume means that the functions are not currently implemented in newlib. On the other hand, SDK:clib2/include/setjmp.h looks like those functions might actually be implemented.
Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450
Why on earth didn't you use newlib? That's what it for?
Because this is a library and I read somewhere that one had to compile with -nostartfiles -nostdlib. Besides, it wouldn't be MOS compatible I suppose. And it's fun to implement stdlib :)
Quote:
If they are amiga hooks make sure you use CallHookPkt() and make sure the argument order is correct.
They are not, they are functions. But the examples have bugs; they don't return 0 from the de/compress hooks as the docs say that should unless they want to abort. Seems the docs are wrong and only the progress hook responds to any return value.
@trixie
Quote:
This sounds like a strange thing to do. I really wonder what stopped you from using newlib, as Broadblues has suggested. In 2015 and in assembly????? I really want to hear the story.
As salass00 said, setjmp/longjmp cannot be implemented in C because they play magic tricks on the C code itself. Need 100% control of register usage and the stack since calling longjmp (from anywhere deep inside other code) causes setjmp, somewhere else in the code, to magically return. longjmp never returns, setjmp returns instead. Pretty cool :)
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Quote: Why on earth didn't you use newlib? That's what it for?
Because this is a library and I read somewhere that one had to compile with -nostartfiles -nostdlib. [/quote]
You don't want believe everything you read on the internet you know
But seriously , -nostdlib is optional, especially now that we have newlib as all you need to do is open newlib.library and initialise INewlib in your library startup. newlib.library handles all the process context stuff internally so you can even call stdio from a .library.
Quote:
Besides, it wouldn't be MOS compatible I suppose.
AWeb for MOS uses clib inside the jpeg / png / gif awebplugins so it's definitle possible to use their clibrary in a .library. Can't recall the details though.
Quote:
And it's fun to implement stdlib :)
Hmm, eductational certainly, fun I'm not so sure
Quote:
Quote:
Quote: If they are amiga hooks make sure you use CallHookPkt() and make sure the argument order is correct.
They are not, they are functions. But the examples have bugs; they don't return 0 from the de/compress hooks as the docs say that should unless they want to abort. Seems the docs are wrong and only the progress hook responds to any return value.
It could of course have been soved using either clib och newlib but I got a headache thinking about it. There are only a few simple stdlib functions I needed so it was faster to implement them rather than try to get newlib or clib in there (at the time). Now I realize newlib is a normal library it could have been fairly easy (on AmigaOS).
This was I can also easily profile the usage of memset and memcpy. And also pretend that fwrite can take a BPTR instead of a FILE*. Makes everything MUCH easier
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
I just altivec-optimized memcpy and memset from plain byte-loops to altivec-versions created specifically based on statistical analysis and gained between 11-23% speed in decoding ONLY by optimizing memcpy and memset!
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Would be interesting to see how CopyMem and SetMem scores here. Can't use CopyMemQuick since the copy data is always totally misaligned due to RGB triplet. The setmem calls otoh. are pretty much always 16-byte aligned due to the altivec source data from libjpeg-turbo.
Software developer for Amiga OS3 and OS4. Develops for OnyxSoft and the Amiga using E and C and occasionally C++
Are IExec->CopyMem and INewlib->memcpy definitely AltiVec optimised? I'm not so sure, although I do remember it was being toyed with at one stage. Certainly they are well optimised in other ways though.
I've been trawling all my old e-mails and trying follow all the discussions on the memcpy/CopyMem subject. The most recent being a couple of years ago, but I did find this:
newlib.library 53.19 (7.1.2012) <ssolie>
- Changed memcpy()/memset()/bzero() to use IExec->CopyMem()/IUtility->SetMem()/IUtility->ClearMem().
The idea is to let the kernel handle any optimizations and avoid duplicating the code for these functions.
It doesn't look like anything has changed with that since. I am 99% sure the kernel has no AltiVec optimisations in place at all for these functions, which means neither does newlib. It may also be the case that the X1000/PA6T has less well optimised CopyMem() compared to other machines. So, using an AltiVec memcpy should well be worth it on a G4 and PA6T.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
