Rational Number library

I explained how ASH worked in a nutshell: it compiles source code into a data structure and then operates over that data structure. You just acknowledged my saying that, but did you understand it?

3) Ed Ort puts things pretty aptly when he writes "the Java virtual machine knows nothing of the Java programming language", so by "meeting JVM requirements" I mean "is valid Java Bytecode".
Fine. The ASH parser/interpreter, like the rest of KoLmafia, is written in Java and compiled by the Java compiler into Java Bytecode. There is nothing special about the ASH parser/interpreter in regards to the JVM or Java Bytecode. I don't understand why you keep bringing it up.

As I tried to make clear from the outset, I have a limited understanding of how ASH becomes bytecode to be executed by the JVM and what compile time optimizations, if any, get performed in the process.
It's very simple: ASH programs do not get compiled into Java Bytecode to be executed by the JVM. Got it?

I don't know why you're pissed off, don't take offence to use of the word "kludge".
Why not? The word "kludge" is a pejorative. ASH is not a "kludge" by any definition of the word.

Java, by their own admission, had terrible support for scripting languages in earlier versions.
I don't think that has anything at all to do with ASH. We are not looking to allow user-supplied Java "scriptlets" to be bundled up and called by KoLmafia
 
Sorry Veracity, I did not mean kludge in the pejorative sense. I would consider many of my own functions in ROFL.ash to be a "kludge", which doesn't mean they are written poorly, just means they get the job done in the best way they can given the limitations of their respective environment (in my case ASH, in your case J2SE 1.4).

Thank you for taking the time out to explain ASH to me. I'm looking to build a fastdebug JVM from OpenJDK so I can gain a better understanding of what is actually happening here.
 
... you need to view ASH as data, not code. ...

Von Neumann architecture. Code is (a form of) data.

-----
Upon some reflextion, you could say that the execution (runtime) stream of ASH code becomes a stream of JVM bytecode (ordered by how it's executed) [1]. This could probably be useful abstraction in some theoretical analysis.
It doesn't help optimization. I mean, we have techniques like "Trace optimization" which improves prediction rate on branches (and decisions on what-to-JIT) based on what data was actually used in the past of this run of the program, but I don't think that will help much in this case - first you have the processor optimizing JVM's code, then you have JVM optimizing mafia's code, and then you don't have mafia optimizing ASH code in this wat, at least to my understanding.
That's way too many layers of indirection, I expect the effects through them will be too chaotic to reliably improve performance.

[1] maybe clarification: I don't mean program code in memory, I mean the sequence of codes seen by the processing unit (processor, JVM, mafia, ...). A loop like while (true) { i++; } will be seen as infinite stream of i=i+1 instructions. Did I make that sufficiently beaten with a dead thread?
 
This... threadjack has gone on longer than it probably should have. Can we move this discussion to a different thread, please?
 
Back
Top