stassats

I did that to write simd routines for sbcl: https://github.com/sbcl/sbcl/blob/master/src/code/arm64-simd... Probably the best way of writing assembly, can evaluate the function immediately, use macros and any other code to emit instructions, even can print register values (instruction-level stepping would be even better, but too much work).

Still 40 years to go.

I have also seen some outright crashes on the new GC.

The tricks to avoid multiplication (and division) are probably worth a whole post.

  x * 6:
  lea eax, [rdi+rdi*2]
  add eax, eax

  x * 7:
  lea eax, [0+rdi*8]
  sub eax, edi
  
  x * 11:
  lea eax, [rdi+rdi*4]
  lea eax, [rdi+rax*2]

And on modern CPUs multiplication might not be actually all that slow (but there may be fewer multiply units).

The text mentions that it can also do multiplication but doesn't expand on that.

E.g. for x * 5 gcc issues lea eax, [rdi+rdi*4].

ABCL is really slow.

A good strategy if you don't care about fixing bugs.

That shouldn't mean that it doesn't return a NaN. Things are generally not optimized away because of NaNs. E.g. in GCC, abs(c) > -1.0 is not folded, unless building with -ffast-math

That fix has limited applicability. x * x is also a non-negative float. But abs(x * x) is not optimized. Or abs(abs(x)+1). GCC, for example, does know that.

(+ 2 (id "2")) may also produce a compile time warning. Nothing precludes from having a special rule for that. Like (+ 2 (print "2")) does warn.

changes in the Qt project made the technique used by the Qt4 bindings impractical for Qt5 or Qt6 - at least that was my understanding when I looked into it.

It was hard to do reasonably with qt4 already. The best solution would be to support the C++ ABI natively, but that's never going to happen.

Why does SBCL not use LLVM?

Why doesn't GCC use LLVM? Why is Zig writing their own backend?

lack of tail-call elimination

But lisp doesn't need TCO.

You can turn them back into rationals, (rational (sqrt 2d0)) => 6369051672525773/4503599627370496

Or write your own operations that compute to the precision you want.

(safety 0)

Please, don't do that!

any system that relies on information that was typed into a REPL three-months ago and is now only stored in the binary state of that REPL and nowhere else is totally insane as a production product.

Nobody does that.

roadrunner is petaflops of FP32

Isn't it actually FP64?

Using EAX is one byte shorter, so it might be doing that inadvertently.

Common Lisp. The dynamic-extent declaration allows for stack allocation.

because 64-bit ARMv8.0 lacks a POPCNT instruction

It does have this: https://developer.arm.com/documentation/ddi0596/2021-09/SIMD...

And GCC happily uses it https://godbolt.org/z/dTW46f9Kf

There's M-:

CNT on arm64 counts 8 or 16-bit elements too.

SYS:WITHOUT-GCING is better but is still fraught with danger (that's why I didn't mention it).

That's not related to garbage collection.

That's a recipe for disaster. Never do that.

What drives people to attempt to persuade others that Lisp is not practical?

it's different enough than other languages it confuses people.

And javascript integers (or lack thereof) don't match CL integers. So if you want to interoperate between distinct languages you do have to consider the differences anyway.

It's not. Reader macros don't take s-expressions, they take characters.

Sure, what's so special about it?

(get-macro-character #\() => SB-IMPL::READ-LIST

(get-macro-character #\)) => SB-IMPL::READ-RIGHT-PAREN (that one just signals an error, the read-list one picks up the closing #\))

Ok, I added the dates.