On 18/05/2017 12:37, Rhodri James wrote:
On 18/05/17 02:12, bartc wrote:
So tell us Bart, what do you think are the chances that your Q
compiler will
*just work* with no modifications at all if somebody tried to build
it on
an IBM AS/400, or under BeOS?
Maybe somebody can try it:
https://github.com/bartg/langs/blob/master/qlang/qcc64.c
https://github.com/bartg/langs/blob/master/qlang/pcc64.c
I don't have my RiscPC here at work, and anyway I'd need the 32-bit
versions,
(Try same urls but with '32' substituted.)
but I had a quick look. I didn't get as far as checking if
endianness would bite it,
Yes, it might well do (not having tested it, I don't know). But, so
what? What am I supposed to do about it? If I had my hands on such a
machine, I could try it out. And if there was actually such a problem,
then I might fix it. But the last non-little-endian cpu I coded was in 1978.
but (a) you have no leg to stand on
criticising configure scripts with that file,
You think so?
After the first 50 lines, there are no #includes, no #defines, no #ifs
or #ifdefs, in fact I think there are no uses of macros at all. And no
#includes for anything other than a few standard C headers.
Everything referenced is also within that one file.
Utter bliss compared with my experience yesterday trying to get some
CPython modules compiled. #defines, #includes and #ifs left right and
centre. Code specific to MSC or GSC sprinkled like confetti (there's
even an #include <windows.h> in there, God knows what is for). And the
actual include files are all over the shop.
You lose the will to live chasing up every single thing that comes up.
(I was trying out my own C compiler: it eventually got 2/3 of the way
through ./Modules/main.c, but it reported wrong # of arguments to
Py_FatalError. Where's Py_FatalError defined? I don't know.)
and (b) I think you may be
making assumptions about non-aligned pointers that will kill you on
ARM3, and are horribly inefficient elsewhere.
I've just tried it on an original raspberry pi, with 32-bit ARM (can't
tell you what type). My jpeg decoding benchmark ran about 4 times as
fast as the Python version (with exactly the same algorithm), albeit
with some ancient version of Python.
And my design lends itself to being easily accelerated by overlaying
some ASM code (I do this on x64 but haven't got round to it on ARM).
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
