So, is there a third option that I'm missing? Other opinions?
The third option would be a plain text format which is easy to parse but still covers the spec well.
I'd say that we should store the SPDs as binaries - these are easy to use at build time, and there's no reason to build them every time. They change, but infrequently. Then we need a better tool.
It would be really nice to have a tool to update the binaries in a reasonable way. Using a hex editor on the binary or updating hex values in a table are just as bad as far as I'm concerned. The hex value text file is just easier to review, but you still have to go to the JEDEC specs to know what the heck just changed.
It would be really handy to have a tool that would read in a binary SPD, and allow you to edit the JEDEC values. It should understand all of the different JEDEC SPD specs. The easiest way would be to interpret the binary SPD and output all the fields to a text file where they can then be edited. Then it could read the text file and generate a new SPD.
At that point, it doesn't much matter what language it's written in - it's not in the critical build path. I think Ron volunteered to write it if we use go. :)
Alternatively, the text files could be stored as text and generated every time, but this puts the tool back in the build path and forces constraints on the language. Back to writing it in c? Or we could store both binary and text and just use the binary at build time. This allows for ease of review and ease of use.
Martin