koehlma / emsys Goto Github PK

Add a nice README file containing at least:

• a short description of what we did
• the video part of the presentation as .gif

In order to:

• be able to compile most of main.c with other compilers / static analyzers
• re-use it for simulation/whatever

As the processor doesn't do any relevant caching anyway, and "pack" only applies to fields that don't also use __alignment__, this doesn't break anything. However, it (should) free up quite a few bytes.

Either use #pragma pack(1) in some global header (including tinpuck!), or compile with -fpack-struct=1.

Currently, controller is a big agglomeration of nearly all other pieces. It's so confusing that I actually don't know whether it's meatball, hairball, or god-object.

Suggested approach:
No idea, but it might involve:

• kicking approx, moderator, and IR-stab out of controller
• merging TCE into victim finder
• bundling TCE, VF, VD into a single "search" module
• bundling PF and PE into a single "finder" module

Process

Actual:

• ask the user to run some scripts
• ask the user to paste the output into space.c (alternatively: hope that it's fresh enough)
• call make run-space, which does some sizeof magic on the pasted code

Expected:

• call make run-space, which looks at the actual output produced by gcc-xc16 and somehow parse the elf / object files in some way

Accuracy:

Actual:

• hope that the differences between the platforms aren't too big to disturb the result too greatly
• hope that the regexes work perfectly (hint: they probably don't, given the amount of trickery and sheer length)
• hope that there is no further padding going on

Expected:

• the resulting byte count is identical to the amount used up by the .bss, .data, and specially aligned sections (e.g., _0xf6b9839857992879)
• there are no hidden costs or over-estimations
• even static allocations by libm and libc

Representation

Actual:

• manual choice of "root objects":
  • Tin Bot library
  • tinpuck library
  • struct TinBot
  • struct Controller
  • struct BellmanFordState
• manual, empiric thresholds
• other than this manual "tree walking", flat lists of fields / variables

Expected:

• tree-like approach: division by source folder, then file, then fields
• automatic expansion of the most important points (should be similar to what I chose manually)
• bonus points if interactive (but that's really not necessary)

• when computing a path to the victim, it's okay-ish to drop a single update
• when computing the way out, we're the only one anyway
• clearing the area "around" the goal might interfere with incoming map updates

Suggestion: implement some hal_{g,s}et_map_locked() such that T2T updates are dropped instead of potentially messing up everything.