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

   1 # 2016/08/11
   2
   3 ## 07:22
   4
   5 What I will need is an object format for the generic namespace blobs.
   6
   7 ## 07:26
   8
   9 I could use standard ELFs with relocations, however the blobs would not be
  10 directly ROM executable and such. So I suppose what I can do is have the code
  11 and data treads placed in the file and the table of contents placed at the end.
  12 There would be one for classes and another for resources. Although it may be
  13 possible to have relocations and not have them at the same time. Relocations
  14 could be useful for the end linking process into the SquirrelJME binary.
  15
  16 ## 12:28
  17
  18 I received the Creator CI40 today, so this will be an interesting device to
  19 develop for.
  20
  21         # uname -a
  22         Linux OpenWrt 4.1.13 #1 SMP Tue Jul 26 02:49:14 UTC 2016 mips GNU/Linux
  23
  24         # cat /proc/cpuinfo
  25         system type             : IMG Pistachio SoC (B0)
  26         machine                 : IMG Marduk - Ci40 with ca8210
  27         processor               : 0
  28         cpu model               : MIPS interAptiv (multi) V2.0  FPU V0.0
  29         BogoMIPS                : 363.72
  30         wait instruction        : yes
  31         microsecond timers      : yes
  32         tlb_entries             : 64
  33         extra interrupt vector  : yes
  34         hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
  35         0x0ffb, 0x0ffb]
  36         isa                     : mips1 mips2 mips32r1 mips32r2
  37         ASEs implemented        : mips16 dsp mt eva
  38         shadow register sets    : 1
  39         kscratch registers      : 0
  40         package                 : 0
  41         core                    : 0
  42         VCED exceptions         : not available
  43         VCEI exceptions         : not available
  44         VPE                     : 0
  45
  46         processor               : 1
  47         cpu model               : MIPS interAptiv (multi) V2.0  FPU V0.0
  48         BogoMIPS                : 272.79
  49         wait instruction        : yes
  50         microsecond timers      : yes
  51         tlb_entries             : 64
  52         extra interrupt vector  : yes
  53         hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
  54         0x0ffb, 0x0ffb]
  55         isa                     : mips1 mips2 mips32r1 mips32r2
  56         ASEs implemented        : mips16 dsp mt eva
  57         shadow register sets    : 1
  58         kscratch registers      : 0
  59         package                 : 0
  60         core                    : 0
  61         VCED exceptions         : not available
  62         VCEI exceptions         : not available
  63         VPE                     : 1
  64
  65         processor               : 2
  66         cpu model               : MIPS interAptiv (multi) V2.0  FPU V0.0
  67         BogoMIPS                : 363.72
  68         wait instruction        : yes
  69         microsecond timers      : yes
  70         tlb_entries             : 64
  71         extra interrupt vector  : yes
  72         hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
  73         0x0ffb, 0x0ffb]
  74         isa                     : mips1 mips2 mips32r1 mips32r2
  75         ASEs implemented        : mips16 dsp mt eva
  76         shadow register sets    : 1
  77         kscratch registers      : 0
  78         package                 : 0
  79         core                    : 1
  80         VCED exceptions         : not available
  81         VCEI exceptions         : not available
  82         VPE                     : 0
  83
  84         processor               : 3
  85         cpu model               : MIPS interAptiv (multi) V2.0  FPU V0.0
  86         BogoMIPS                : 363.72
  87         wait instruction        : yes
  88         microsecond timers      : yes
  89         tlb_entries             : 64
  90         extra interrupt vector  : yes
  91         hardware watchpoint     : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc,
  92         0x0ffb, 0x0ffb]
  93         isa                     : mips1 mips2 mips32r1 mips32r2
  94         ASEs implemented        : mips16 dsp mt eva
  95         shadow register sets    : 1
  96         kscratch registers      : 0
  97         package                 : 0
  98         core                    : 1
  99         VCED exceptions         : not available
 100         VCEI exceptions         : not available
 101         VPE                     : 1
 102
 103         # free -m
 104                          total       used       free     shared    buffers     cached
 105         Mem:        185380      34200     151180         84          0       6888
 106         -/+ buffers/cache:      27312     158068
 107         Swap:            0          0          0
 108
 109 Going to install a Debian chroot since there currently is no Linux kernel
 110 available.
 111
 112 ## 15:11 When
 113
 114 I should probably support reading the blob format before I write it, so I can
 115 have a clue as to how to write it out.
 116
 117 ## 18:17
 118
 119 Appears the CPU on the device does not support denormal floating point
 120 operations, which is totally reasonable, and that the Linux kernel is not
 121 emulating these. I will need to make a note of this and have an illegal
 122 instruction handler for some CPUs to emulate operations on denormals so that
 123 even though they are not implemented by the CPU, the host code can still run.
 124
 125 ## 19:56
 126
 127 I do wonder though if there is an extremely low memory way of writing that is
 128 not a complete mess and is quick to parse while also having some sense of
 129 security. I would like things done in a single pass. What if everything was
 130 a native method, including the class definitions. I really just need code and
 131 resources. However they should not be together at all, since if there is a
 132 breach then data could be executed as code (which would be very bad).
 133
 134 ## 20:06
 135
 136 That actually could be something. Instead of having it where there is just
 137 static data that is handled by an object format reader, instead each namespace
 138 has an entry initialization. Basically this would be generated machine code
 139 that when called will setup the namespace as it should be setup on the running
 140 VM. Everything would essentially be executable for the most part. When a
 141 namespace is desired to be used then its boot code is used which registers
 142 everything. However this code will be shared among all namespaces for the most
 143 part. When namespaces are read, there will need to be linear scan of
 144 everything anyway. The only issue would be determining the size of entries
 145 before they are written and actually known (unless `ZipFile` is used, but
 146 every entry is treated as a stream of bytes anyway). When a classpath is
 147 initialized, the namespace should be scanned and then code linked in as such
 148 and classes registered as needed.
 149
 150 ## 20:08
 151
 152 However, I am kind of going in circles. I want a really fast to output format
 153 that is sane and does not require lots of memory to use, but is easy and
 154 simple to parse. I will need an ending table listing classes and such. So
 155 perhaps I can just dump strings and code into the output, then build up an
 156 ending table. The class table will have references to the class header
 157 information along with fields and methods that are declared in the class (at
 158 known file addresses). Classes in the final table could be sorted by name so
 159 that they are easier to be found. Resources can be pretty much the same. I can
 160 use a single output stream format for this. There would be no string table at
 161 all. There would have to be an import table (for classes and field offsets),
 162 but just the information that is needed to initialize it. So essentially
 163 structures and code would be together (even though I dislike that) and the
 164 ending table would handle most of the things. So this would be similar to my
 165 original plan but a bit more sane as everything is in tables.
 166