Tolerate short representation of 0 in register updates.

Fixes #17, in which a user showed a trace snippet from a Neoverse-N1
in which writes to floating point registers from xzr were shown with
only 8 zero hex digits instead of 16. However, that Tarmac producer
shows writes of non-zero values from ordinary registers at full width,
so I've made this special case apply only to zero-valued data.

lib/parser.cpp

@@ -794,7 +794,21 @@ class TarmacLineParserImpl {
                     contents.append(2 * reg_subrange_skip_hi, '-');
                     hex_digits_expected -= 2 * reg_subrange_skip_lo;
                 }
+                size_t data_start_pos = contents.size();
                 while (contents.size() < hex_digits_expected) {
+                    if (tok.iseol() &&
+                        contents.find_first_not_of('0', data_start_pos) ==
+                            string::npos) {
+                        // Special case: if the line ends with fewer
+                        // hex digits than expected, but all the
+                        // digits we've seen are zero, then we assume
+                        // that the Tarmac producer abbreviated a zero
+                        // value on the grounds that it was boring.
+                        // This is seen in Neoverse-N1 RTL, for example.
+                        contents.append(hex_digits_expected - contents.size(),
+                                        '0');
+                        break;
+                    }
                     if (!tok.isregvalue())
                         parse_error(tok, _("expected register contents"));
                     consume_register_contents(tok);

tests/parsertest.ref

@@ -221,6 +221,12 @@ Parse warning: unsupported system operation 'AT'
 * MemoryEvent time=947020259 read=false known=true addr=9884cfb0 size=8 contents=fe
 --- Tarmac line:                        000000009884cfa0  00000000 00000007 ........ ........  NS:000000009884cfa0   NM ISH IWBRWA
 * MemoryEvent time=947020259 read=false known=true addr=9884cfa8 size=8 contents=7
+--- Tarmac line:       16465 tic ES  (00000000000001ac:9e6703e5) O el3h_s:         FMOV     d5,xzr
+* InstructionEvent time=16465 effect=executed pc=1ac iset=A64 width=32 instruction=9e6703e5 disassembly="FMOV     d5,xzr"
+--- Tarmac line:                     R V5<63:0> 00000000
+* RegisterEvent time=16465 reg=v5 offset=0 bytes=00:00:00:00:00:00:00:00
+--- Tarmac line:                     R V5<127:64> 00000000
+* RegisterEvent time=16465 reg=v5 offset=8 bytes=00:00:00:00:00:00:00:00
 --- Tarmac line:     1234567 cs E dummy header line to reset timestamp for next two lines
 * TextOnlyEvent time=1234567 type="E" text="dummy header line to reset timestamp for next two lines"
 --- Tarmac line:                     LD 000000007ff80fe0 ........ 44444444 ........ 2222..11    S:007ff80fe0    nGnRnE OSH

tests/parsertest.txt

@@ -198,6 +198,20 @@ Tarmac Text Rev 3t
                     ST 000000009884cfb0  ........ ........ 00000000 000000fe  NS:000000009884cfb0   NM ISH IWBRWA
                        000000009884cfa0  00000000 00000007 ........ ........  NS:000000009884cfa0   NM ISH IWBRWA
 
+# ----------------------------------------------------------------------
+
+# Trace snippet seen from the execution testbench provided with
+# Neoverse-N1 RTL, in which a write to a d-register from xzr (which
+# also zeroes out the top 64 bits of the containing v-register) is
+# displayed as two register updates each covering a 64-bit range, but
+# with only 32 bits (8 hex digits) of zero data shown, violating the
+# usual convention that the data is written with a number of digits
+# corresponding to its bit width.
+
+      16465 tic ES  (00000000000001ac:9e6703e5) O el3h_s:         FMOV     d5,xzr
+                    R V5<63:0> 00000000
+                    R V5<127:64> 00000000
+
 # ----------------------------------------------------------------------
 # Manually written tests