omarandlorraine
commented
2 years ago Right now strop outputs assembly/machine code - this is OK if you're going to run it directly on some architecture,
This is the intended use-case. Most compilers have asm directives you can use to embed what strop comes up with. Of course it's not cross platform, but as the programmer you probably know what the target is (or what the targets plural are), so then you can generate the assembly for what you need.
but what if you want to put the idea into code to compile it for any architecture?
LLVM has a C backend (or least, it has had. I don't know if it's still there), which can be used for compiling a C program, and then outputting optimized C. Maybe a C backend could be useful for strop as well. Of course, you don't get access to the carry flag and things like that, but.
For example, fast-inverse-square-root was implemented in C, not x86 raw assembly.
It was, but not in a platform-agnostic way. It assumes IEEE-754 floats and maybe other platform specific assumptions. It has undefined behavior all over. I imagine that same routine would not do the same thing on the Commodore 64 or whatever. For these reasons, it could be argued that it would have been better to do it in assembly. That would also cut out needing to go through memory for that line which casts the float to int and back again.
So pseudo-code would further open up the door to use strop as a real tool for finding real performant solutions to problems that currently require verbose/expensive implementations in order to be correct.
Do you have a particular one in mind? Maybe the intermediate representation from a compiler, like GIMPLE or something? Or would C actually do the trick?
My example is approximately what strop is eventually intended to solve, right? :)
Exactly so.
P.S. this is my first issue here, how'd I do?
This is the kind of thing I want to hear about, so it's good 🙂
LoganDark
Right now strop outputs assembly/machine code - this is OK if you're going to run it directly on some architecture, but what if you want to put the idea into code to compile it for any architecture? Every architecture has a version of some primitive operations, like bit shifting and masking, moving bytes around and so on, and of course variables/registers. For example, fast-inverse-square-root was implemented in C, not x86 raw assembly.
I think a "holy grail" of strop will be when it can come up with a fast-inverse-square-root algorithm - or even a version that's even faster - as pseudo-code, such that it's a relatively straightforward port to C or Rust. Right now, strop is compiling to one architecture, and then you have to reverse-engineer it.
To achieve the desired effects, the "pseudo-code" would have to be interpreted by strop "as if" it were compiled for some abstract machine, for the purposes of achieving the desired behavior from the pseudo-subroutine. If this is possible, strop wouldn't be useful just for generating subroutines, but for generating new algorithms that can be implemented in any programming language.
For example, I want an sRGB color blending function that doesn't use any floating-point math. It can be implemented by a couple lookup tables, but then you spend kilobytes of space (or 512 bytes if you want to completely defeat the gamma curve) for them.
Strop could generate ridiculous stuff that happens to do exactly what I want for the entire input space (all 56 bits of it), but that's no use if I can't decode the assembly (this is not a trivial algorithm).
So pseudo-code would further open up the door to use strop as a real tool for finding real performant solutions to problems that currently require verbose/expensive implementations in order to be correct. My example is approximately what strop is eventually intended to solve, right? :)
P.S. this is my first issue here, how'd I do?