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.
10:08
Had this interesting dream. World took place in a very cubical place, so it was kind of like how Minecraft is. However, there was no mining invovled really. Parts of the world were city with apartments and businesses, some parts were highway, while others were outside areas, there were some mines. However digging in mines the wrong way can cause the mine to collapse which would kill you. The main part was that this normal guy was taking all of this special water. Once he took it all, he figured out how he can become powerful from it. So it is a rather tough boss fight. However, the problem with the water is that is evaporates quickly if it is not contained well. There are some creatures such as skeletons and such which spawn near the water, but if the water source dries up the skeletons just die. So the final boss would be breaking the water containers while this super powerful boss is attacking you.
Other than that, I suppose I should get IFEQ going.
10:40
Just thought of something, NARF can use the stuff in StandardRISCTranslator and by extension the architecture specific code generators when it generates code. It may have to alter some things however but it might work. This would reduce re-adding support for target architecture although NARF would be unable to take advantage of specific architecture features unless it were added in the StandardRISCTranslator as extra operations. Specific features such as vectorization and such. So NARF would basically run POIT to have operations generated for a generic program, then that program gets optimized, then it runs through an architecture specific generator. By this layering of NARF on POIT I can save time and code.
12:40
Middle click paste is a bad idea, especially since there are two clipboards in X.
13:20
For the testing framework I believe I am going to go for a testing which is based on results rather than actual tests to so speak. So instead of saying pass/fail, the result should match. This would remove the binary nature of it and also allow for better debugging because one can see the actual result rather than just having it say yes or no.
13:27
Another thing to determine how to actually find the tests to make and have it done automatically, rather than being manual. I could leverage hairball for that. If I could get annotation processing done it would work, but I have had some trouble with it in the past when it refused to actually process classes. Another alternative I can have every class able to be instantiated, which then a test is performed on it. It would implement a tester and would contain a single test method which does all the required tests and such. That would simplify searching for methods to invoke.
Also with the result based system, I can store the result of the reference implementation in this project which must be matched to.
The testing framework would hopefully help remove some bugs and prevent regressions of things. It can also test to see how compatible a code generator is when it has compiled code and such.
13:39
I could also use an option to include the test framework in the kernel to make some things a bit easier for example. I suppose for now it should be enabled by default then once things get stable enough, it can be disabled by default. At the start, code is going to be run kernel space so I will need some tests at least to see if things are valid. The results can just be printed to the screen. Tests could be both kernel and userspace (with the userspace using the kernel stuff). Since execution of code will vary slightly when in kernel mode it should be tested also. A unified set of tests also makes things simpler too.
14:24
My unit testing code actually was pretty horrible because I had written it without actually compiling it.
14:30
I should check in MutableOpCode if input values which are negative get sign
extended when getting the longValue() of it. And luckily I already do that,
but it is always good to double check.
17:48
One thing though, is how volatile fields will be handled. On single CPU systems it is not that big of a problem due to shared caches. However when it comes to multiple CPUs, there will need to be some kind of a memory clear. So I suppose what I need is a reference which tells me that a field is volatile. If it is then a branch is taken which does volatile work (force memory flush) before the field is read from. Then for writing the field there will have to be the same check for memory flushing also. Some CPUs will not need any of this, while some will just need only read or the write, and others will need both to exist. Depends on the memory ordering of the CPU. Although branches would slow it down a bit, that is a safe way to do it since it would work. Speed would suffer from a double read and a branch for every field though. However POIT is not aimed for super speed and is for stability and simplicity. NARF which will be based on POIT will end up having the same generators, however it optimizes everything else and it is possible that reading/writing a field would be pointless to exist because code is never reached.