Python and the need for speed

[bartc]

On 19/04/2017 12:27, Chris Angelico wrote:
> On Wed, Apr 19, 2017 at 8:33 PM, bartc <bc at freeuk.com> wrote:

[Warning: this is nothing to do with Python.]

>> My interpreter is on github as /one/ C source file (a link would be
>> inappropriate here). People can compile it with -O3 or -O2 if they wish.
>> It's a bit simpler than building CPython, and OS-neutral; that was
>> deliberate.
>
> Then send me a link, and I'll try to compile it. You'd be surprised
> how easy it is to be non-OS-neutral. Have you compiled it on the three
> major platforms of today (Lin/Win/Mac)?

It should work on Windows and Linux, but I've only tested with gcc and 
Tiny C recently. I don't have a Mac.

The original link was for 32-bits, as that tended to be faster, but I've 
redone versions for both: click on either pcc32.c or pcc64.c here (and 
do what you have to do to download to your machine):

https://github.com/bartg/langs/tree/master/qlang

Build instructions are in the sources, but are basically just:

    gcc pcc64.c -opcc -lm

Test using:

   ./pcc hello             # .q is assumed

I provide hello.q, or you can key it in; create a file hello.q with:

   proc start = println "Hello, World" end

To test on something bigger, download mc.qa (a composite of 27 .q 
files), and try that:

   ./pcc mc.qa

(mc.qa is an entire compiler for my static language; it should 
(byte-code) compile instantly then give usage instructions. To try it, 
copy hello.q to hello.m - the two languages conveniently have the same 
syntax - then try:

   ./pcc mc.qa hello               # defaults to .asm output I think
   ./pcc mc.qa /c64 hello          # hello.m to hello.c

I think it took 10ms to compile the 23Kloc of mc.qa to byte-code on my 
current machine.)

If you want another example of a trivial-to-build project, try:

    https://github.com/bartg/langs/blob/master/bccproj/mcc64.c

This is my C compiler in one source file (although not finished). Also 
OS-neutral (to run; however generated code runs on Win64).

This is how I wish other people would distributed their open source 
projects!


 > You'd be surprised how easy it is to be non-OS-neutral.

It's not so simple. By OS-neutral I mean code that doesn't depend on 
special features of either OS (Ie. Windows and Linux). Not conditional 
code that does either Windows stuff or Linux stuff.

This means the 'pcc' program above is restricted (it needs either 
LoadLibrary/GetProcAddr or dlopen/dlsym to be able to access external 
libraries, although essential functions are patched in).


-- 
bartc