support AllegroCL 10.1 (Part I)

[franzinc]

This changeset provides support for Allegro CL 10.1 (modern cased mlisp not supported). The updates are mostly concerned with floats printer compatibility.

All tests passed for both Allegro and SBCL in a 64-bit Linux environment, except these 4 take siginificantly longer time to even finish in Allegro:

• test-compiler-hook
• test-sohaib-gh-361-regression
• test-compiler-hook-random-4q
• test-chp-files

Therefore, in this Part I PR, we only present updates that are only concerned with "correctness". Hopefully, in Part II, we will present optmizations that solves the performance problem.

Change-Id: I25ff3ac8e9a696b8550bebb828b87e0858a7268c

[ghost]

Hello @stylewarning , I will explain many details in the PR soon.

[ghost]

The most notable change is wrapping (format nil "~F" ...) forms with a lexical binding of a special variable *read-default-float-format*. In Allegro, printing floats follows the ANSI standard which is described here. Note that:

If the format of the number does not match that specified by read-default-float-format, then the exponent marker for that format and the digit 0 are also printed.

For example, as *read-default-float-format* evaluates to 'single-float by default, this works as expected:

CL-USER(1): (format t "~F" 1f0)
1.0 
NIL

However, if it's printing a double float, the exponent marker will be printed, because *read-default-float-format* is different from 'double-float :

CL-USER(2): (format t "~F" 1d0)
1.0d0
NIL

Binding *read-default-float-format* with 'double-float will print the expected result:

CL-USER(3): (let ((*read-default-float-format* 'double-float)) (format t "~F" 1d0))
1.0
NIL

This is why you will see a lot of re-binding of *read-default-float-format* in this PR. Hope it makes sense to you.

[ghost]

Hello @stylewarning, I have left a few more detailed explanations. Feel free to leave comments and suggest edits later. Thank you.

[karlosz]

@franzinc I have recently discovered in #761 that quilc spends almost all of its time calling COMPILE several times. This has huge performance implications, since the speed of a quilc compilation is thus tied to how fast the Lisp compiler does its job at runtime. I suspect this may be the root of some of your performance troubles. I suggest trying again once #761 is finished, since that will remove these runtime calls to COMPILE.

[ghost]

@karlosz Hello Zhang, thanks for the advice! Is it possible to show me your experiment code? I'm currently profiling (cl-quil-tests::test-compiler-hook) but it doesn't show any clues related to COMPILE.

[karlosz]

I sampled a couple seconds of the whole test suite and used an sbcl specific statistical profiler to produce the profile linked. Not sure but when you run the test suite I expect there to be something related to using the compiler at runtime.

[ghost]

The bug seems to be caused by code changes explained by @macdavid313 in this PR files comment: https://github.com/quil-lang/quilc/pull/767/files#r745348410 The code was changed to use APPLY, but there's no list of args in the non-allegro case, which leads to the bug.