08:04
Ok, so going to take a break from the UI and launcher code and instead perform
a refactor and moving around of all the stuff under native-compiler.
08:11
For the basic interpreter in the tests during the cleanup, I can have it base
off the kernel so that way I can develop a native interface which normal
programs would use and such. So calling interpreter-tests would create a
kernel process to launch applications with for example. This way I can still
work on the kernel and the native interfaces without worrying about the UI
layer. Once I get execution of code in place, I can use that to determine how
code should be started and such (the classpath loading and such). So calling
something such as interpreter-tests would just bypass the launcher
completely and not require it at all. Something I also need is a rename where
I can use regular expressions, so instead of renaming all the classes one by
one manually, I can use sed to do it.
10:19
The interpreter will come in a core portion which just has simple logic. Then
there would be extensions and implementations of the core which have the
actual interpreter loops. This way the same code can be shared and plugged in.
Also the verification of classes and such will be given to the class-path
package. Verification only makes sense when entire classes have been loaded
for the most part.
10:25
The user of the pure interpreter would be the test kernel, so similar to what I have before except it has no launcher interface.
10:54
Going to remove the base NARF exception stuff soon.
10:56
Right now a bunch of code has been commented out and such and prefixed with
a TODO. The test kernel would initialize a kernel, and an interpreter while
parsing the command line to determine what to do. Then once the kernel and
interpreter it initialized, it will setup a ClassPath and then give that to
the kernel to be executed and such. The kernel implementation would then take
it and create a stand-alone interpreter instance which is linked to the kernel.
10:58
I could also remove the old console and the IPC UI since due to the changes in the UI code and my future potential changes, they no longer compile properly or even fit with the current code base.
11:02
Also going to remove the issue codes from the exceptions which came from the NARF code.
11:17
Now that the code compilation and the TODOs are in place, I just have to go back and reimplement those bits using the newly planned route. The test kernel creates a new kernel and setups up the pure interpreter factory and then initializes the interpreter using said factory.
11:26
Also the path separator could support multiple characters, just use indexOf
for strings for splitting.
14:23
The question is, how permissive are the magical kernel calls to be? I could
check the permissions and such in the kernel. However there may be some cases
where inline assembly must be generated and such for something to be performed.
So that the native compiler does not help generate code which contains native
code which could be used for exploitation. Actually, a way to prevent this is
that before assembly is executed, there is a check to see if code is running
in kernel mode (or as the kernel process). So basically before the raw
assembly, there will be a condition and a branch. One thing to consider however
is that assembly code might be needed in cases where the kernel has to do
something. The main library for stuff such as using system calls or getting the
class type of a class would potentially require assembly code. So ideally I can
perform the same thing. If raw assembly is used and a point is a jump target
then the check would be performed again. However, specific access to objects
could be handled by the kernel as a system call anyway. So say for example if
java.lang.Object wants the identity hash code for an object, the assembly
can just create a system call to obtain it. That system call jumps to the
kernel which is permitted to use assembly code. While in the interpreter, there
would be no native assembly so the magical stuff is handled by the interpreter
engine. There would also have to be a means of having a standard raw access
mechanism that can be used by drivers to access block devices for example. I
could also have a mapped region which is simulated as a byte array for
example. So that would mean for any kind of arrays, there is the reference
which specifies the class type and the array length. However, the actual array
data is elsewhere in memory as another block and the array just points to that
data. So if that data is raw memory, this would provide a safe means for
native processes to access areas of memory. This would also enable the drivers
and such to operate without resorting to ByteBuffer magic (even though that
has no mapping mechanism anyway).
14:42
I also should move the magical code down to a much lower package where it is easier to find, but still reserved in a way.
17:33
I actually need to make the JAR class unit public.