assets/developer-notes/stephanie-gawroriski/2016/07/08.mkd

   1 # 2016/07/08
   2
   3 ## 09:24
   4
   5 So I will need to fix all of the version information and figure out a way to
   6 implement standard liblet descriptions. This would be for standard
   7 functionality dependencies. However I cannot find any property which describes
   8 which standard something implements.
   9
  10 ## 09:44
  11
  12 I suppose for other versions and such, I will just use a kind of release
  13 system I suppose. I would say that I will start at `0.0.0`. Once SquirrelJME
  14 is 100% compatible, this will become `1.0.0`. Minor versions in development
  15 will be even numbers such as 0, 2, 4. Although in this case I would ever only
  16 be able to perform 49 releases. So I suppose I will do this at the micro
  17 scale. So initially I will start at `0.0.2` so that it is not zero.
  18
  19 ## 11:42
  20
  21 Something that could work is if there is no line based interface possible and
  22 no graphical interface possible, that there could also be a standard I/O
  23 based interface. If it could support non-blocking read/write (so stuff can run
  24 in the background in a cooperative-like manner) or has blocking read/write. In
  25 the event of blocking, I may just have to have a continue command to continue
  26 execution, unless interruption can be detected in which a prompt will appear
  27 and block. So basically...
  28
  29  * If non-blocking stdin can be read, then input commands can be read without
  30    blocking running programs.
  31  * If interrupts are supported then interrupting will go to a prompt.
  32    * If threads can run in the background, everything would be preemptive.
  33    * If threads cannot run in the background, continuation would be required
  34      before execution continues.
  35  * If stdin blocks and there is no means of interruption then after a certain
  36    point a prompt will appear waiting for a continue unless something
  37    requires some kind of input.
  38
  39 ## 12:14
  40
  41 So what I need is namespace output.
  42
  43 ## 13:44
  44
  45 I would suppose I would need a JIT that is traditional for traditional CPUs.
  46 These would be how CPUs for the past few decades have operated. This would be
  47 nothing non-standard such as esoteric systems or programming languages.
  48
  49 ## 17:46
  50
  51 I would suppose that I could also have a traditional namespace writer also for
  52 specific systems too. Generally all of them will follow the same layout at
  53 least (a bunch of machine code, some tables, etc.). Anything esoteric would
  54 completely not fit at all. It would likely be best if the blobs for each and
  55 every architecture were exactly the same.
  56
  57 ## 18:28
  58
  59 Having the cache output stream created in the namespace processor does not
  60 make any sense. It should instead be created in the namespace writer if a file
  61 on the disk was requested.
  62
  63 ## 19:00
  64
  65 I also have the option of JITting to something that is not a CPU but a
  66 language. I could compile to Javascript but handling of binary files really
  67 depends on the browser it is running on. Alternatively I can target POSIX
  68 shell (which would produce very slow code) or other languages such as Python
  69 (despite not knowing it). I could also target the JVM. Although for the JVM,
  70 entire namespaces are likely to not fit within a single class file. This
  71 would put a limit of 65534 unique constants with 65536 fields and 65536
  72 methods. Each namespace would pretty much have to be written to a JAR in a JIT
  73 like manner that allows for individual VM instances to exist. This would mean
  74 that all methods would essentially be static (since instances would not
  75 make as much sense). Objects passed around would be virtual object
  76 representations. Every method would have to have as a first parameter, a
  77 virtual machine interface of sorts. So targetting Java would be a bit
  78 feasible. At least stuff such as primitive types can be passed around
  79 as-is. However, all objects would be passed with a virtual object
  80 representation for the most part. Then since linear ZIPs are supported (similar
  81 to TAR archives) I can output a JAR like this, then at the end write the
  82 complete entry table. Since I lack an inflate compression algorithm, the data
  83 would essentially be stored. There then could be a stubbed code that acts as
  84 the virtual machine. It would setup some initial objects and then just call the
  85 JITted code.
  86
  87 ## 19:10
  88
  89 The only consideration would be exception handling, would I have actual
  90 handling of exceptions or virtualized exception handling (a switch with a bunch
  91 of goto operations). This would be a rather complex first step however. I could
  92 have an output which generates C source code however. The `OutputStream` cache
  93 form would essentially be a TAR archive containing C source and header files.
  94 Header files would be last, then using preprocessor magic the normal code
  95 generation can occur.
  96
  97 ## 19:36
  98
  99 I suppose I can develop the JIT compiler by outputting to standard C code.
 100
 101 ## 19:50
 102
 103 Then at least with C code, if the JIT compiler starts getting a bit ugly I
 104 can drop some things. Basically this compiler at first would have the potential
 105 for refactoring and being tossed out. I can just use a pre-existing compiler
 106 such as GCC to compile the C code and manually test if it works. Then I can
 107 have more flexibility.
 108
 109 ## 19:59
 110
 111 So yes, I shall work on a C code generator and ignore PowerPC on Linux for
 112 a bit. Then once I have the interfaces required for code generation I can more
 113 easily fit the PowerPC generator into it.
 114
 115 ## 20:58
 116
 117 I suppose when it comes to languages the architecture will just be `language`,
 118 the variant will be `generic`, the operating system will be the target
 119 language. The operating system variant would just be `generic`.
 120