Correct spelling.
[SquirrelJME.git] / assets / developer-notes / stephanie-gawroriski / 2017 / 08 / 24.mkd
blob0be3f872748f15a783f17c011a5985cb2b73fbd5
1 # 2017/08/24
3 ## 01:13
5 You know what if I could make `JITConfig` immutable and then have a branch off
6 of it which provides a set of options and abilities to do things. Instead
7 of having it be extended (which can be error prone and have the base class
8 issue), just have it bring in things. I would have assembler, hil, lil, and
9 some other selections available. But those selections would have pretty much
10 the same exact interface with some slight differences. They would provide
11 options with defaults however.
13 ## 01:18
15 Also, the fragment output can just include some basic constructor bits for
16 some instruction sets such as MIPS, just so it is there to be there.
18 ## 01:26
20 I think instead of the build system calling the JIT and doing whatever, there
21 is something in the JIT which handles it automatically.
23 ## 01:28
25 The JIT basically requires that JAR files are processed and such and they will
26 pretty much always be processed the same way. So I believe the JIT should
27 depend on the ZIP code, have it process an input stream for compilation.
29 ## 01:29
31 Indeed! This way it can manage the cluster stuff itself, this makes the build
32 system much cleaner and will definitely make much more sense.
34 ## 11:46
36 So the binary will be similar to how it was before, just a bit simpler.
38 ## 14:18
40 I can definitely have sections again, just as part of the binary. Each OS or
41 target could more than the text or data sections. Each section though needs to
42 have a load address specified anyway, at least until that is known. Well in
43 reality there just needs to be a single section. But some systems might only
44 use a single section, for example if they are ROM. I think keeping things in
45 single sections would be the easiest.
47 ## 14:22
49 Maybe I should not care about which sections something exists in. Basically I
50 just have a bunch of fragments which can have parts which point to other
51 fragments. But when it comes to linking time, those fragments could be pieced
52 together to make something that works. An optimization could be performed
53 where if the fragments have the same exact data like generated instructions
54 then they can be merged into one. That could potentially work.
56 ## 14:25
58 That will work because I really have no idea how fragments would be laid out
59 and their addresses and such. Doing that at a later step would be so much
60 easier.
62 ## 14:27
64 Basically the linking stage can create a gigantic byte array which is then
65 filled with data based on generated instructions with some special markers
66 and such to determine how some things are handled. Then some basic class
67 information tables can be generated to on the output. The only distinction
68 I will have to make would be PIC based binaries which are not at a fixed
69 memory address. Also an operating system for some things, such as in ROM
70 could have special starting point offsets (like the N64, the ROM header
71 would cause the rest of the code to be pushed off but at a fixed address).
73 ## 14:43
75 `TemporaryBinary` will just not care at all for the process or where things
76 are, it will just hold fragments. Later on the `JITProcessor` can handle
77 output to a linked executable or maybe some internal JIT dynamic thing.
79 ## 15:18
81 Actually for a JIT to function, there needs to be symbol information for
82 methods and fields. Basically anything needed for reflection. I suppose I
83 should design the JIT as a two fold approach, either the initial static
84 environment or JIT environment. This also means the static environment
85 part of the code needs to handle cases where it is JITted.
87 ## 15:58
89 Ok so the temporary binary will just contain linking points and fragments,
90 nothing else. There will though have to be another class which stores the
91 symbol information that is used at link time to do magical things.