DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.
I have a bit complex sorting for fields in the TreeSet for MOC. However it is very odd.
Might be best to just sort by String case insensitive, although I really would like special sub-ordering.
Actually I can cheat in a way and make it still work. The string can have the bit location of the value (the lowest bit) with an appended @# for the name of the field in the map. However, the Comparator would ignore such fields.
Not going to bother, will just sort by case insensitive name.
For some reason in MutableOpCode, getting aa works but AA does not.
I have no idea why this is not working when it should.
Actually it is AbstractMap, the way it looks up entries. It uses the entry set's iterator and performs equal on the key. So in short it will never work the way as intended. I should add this as a test case.
Hexadecimal floating point values should be simple to parse.
No wonder what seems to be correct happens badly. My tokenizer is not putting the x in 0x or 0X for the token.
The input value 0xDE.EADP+17 should result in plainly: 29218208, however my decoder gets 22291723632812500000.
Ok my guess is 222.917236328125E+17, which is actually correct sort of.
0x0.EADP+0 = 0.917236328125 0xDE.EADP+0 = 222.917236328125 0xDE.EADP+17 = 29218208
At the magnitude of zero my value is correct, but with 17 mine is really wrong.
Ah yes, the magnitude of hexfloats is power of two and not base 10, which would explain why it is off. What I need to do then is to convert from the base 2 exponent to a base 10 exponent. Well really the P is *2^n, where the E is *10^n. I need to convert the 2^n to 10^n
Well, BigDecimal does not support log/ln, or supports scale with fractional values so I will need a new way to parse into a BigDecimal.
Going to rework it so the parsing does not create any temporary Strings or StringBuilders, would be best to make it operate entirely on CharSequences. Not only would that be more efficient, but it would be much better too. Due to the lack of log in values though, to support the binary bases of hex floats I will just have to multiply by [2, 10]^n.
I virtually just use String when it comes to parsing since it is quite simple (with substring). The one thing I must check is if the values are converted good. 0xDEADBEEF = 3735928559 is correct.
Appears the computation of the power side of the big decimal is taking quite some time. Perhaps it would be best to have it be done with a BigDecimal instead.
Actually the add operation was taking forever because the scale was really small, the scale was virtual the minimum value since I forgot to set the value accordingly to zero. The value I want is 29218208, however the value I get is 492466601984.
[FINE] Building! [FINE] Made constants. [FINE] Add 222 + 3757000 [FINE] == 3757222 [FINE] Multiply 3757222 * 131072 [FINE] Done! [FINE] 0xDE.EADP+17 = 492466601984
Looks like the fractional part has a bad scale to it.
Looks like scale is negated to the power, hard to tell that because the font on the documentation is microscopic. So that results in a closer 0xDE.EADP+17 = 29590421.504.
Now fixing a scale off by one, I get: 29147227.7504. Closer but still off. The resulting before the scale multiplier is 222.3757 wheras the correct values are 0x0.EADP+0 = 0.917236328125 and 0xDE.EADP+0 = 222.917236328125.
The correct way to add the fractions together is to add the inverse of them together.
Neat! I saw the International Space Station before! It moves very fast and is bright like Venus. There appears to be a 3 day window where it can be seen from where I am for a few minutes, tomorrow at 9:16PM and the following day at 8:37PM. It was distracting from my current coding, but it is rather neat since it may be a rare sight.
Doing a slower add multiply for the fraction gives me 29218208.000000000000. That is the same number as 29218208, so it is correct now. I can go back to the Assembler and setting fields from BigIntegers.
And now MutableOpCode.Value can be set with BigIntegers.