Close

PK2 device file (Pseudo-) decompilation, ardpicprog-java

A project log for piculear

Coercing the GPIO of an arbitrary device to control a simplistic PIC programmer.

psmaypsmay 07/15/2014 at 21:200 Comments

A couple of new levels of abstraction have been added to my PK2 device file analysis suite. Now included in the build is an intentionally C-like output file that fashions each script as a void function.

For the version of the device file I'm currently using, instances of LOOP, LOOPBUFFER, and GOTO_INDEX are all successfully resolved into counting for loops. I haven't finished the translation of IF_EQ_GOTO/IF_GT_GOTO, but since all instances of those are in the DBG* scripts (what I gather to be for in-circuit debugging, which I'm not planning to implement anyway) they're not a major priority. Not counting the latter, there are no gotos to speak of in the output.

Other semantic reworks are also included. For example, DELAY_SHORT and DELAY_LONG are normalized to delay_ns, whose argument is always an integer (with a human-friendly scaling of the value in a comment). I/O via the download/upload buffers and the data/clock lines is decomposed in a sort of functionalesque, orthogonal style; WRITE_BYTE_LITERAL(b) becomes putLineByte(b) while WRITE_BYTE_BUFFER() becomes putLineByte(getBufferByte()).

The result is intended to be expressive rather than efficient; expressive code can be optimized straightforwardly, but optimized code tends to be difficult to make expressive.


On a somewhat related note, to determine how easily it could be done, I ported the ardpicprog host program to Java. It turned out not to be all that difficult, and RXTX (the serial library) works nicely wherever it's supported at all. I have two branches: The master branch is written to be a Java program, while the pythonization branch includes a good deal of extra work to use Python-like idioms so that porting to Python would be less infeasible. Refactoring Python is a great deal more difficult than refactoring Java, so getting it right the first time seems pretty important.

After working on this for a while, I now wonder whether I like Python enough to try to port anything to it or maintain something in it. As a matter of personal taste, I like static types and various other comprehensive static checking facilities that prevent uncaught run-time errors. I might proceed to make the piculear host code in Java (or Scala) and beg for help porting it down later.

Discussions