)]}'
{
  "commit": "76c51bed59920115074e658fb2cfa76c68eb76ed",
  "tree": "0711a6f992012cd198f6c4695456a33bc3889584",
  "parents": [
    "eef4ff9b707d738322a5dca82a6a9b0aad76a26e"
  ],
  "author": {
    "name": "Jeff Law",
    "email": "jeffreyalaw@gmail.com",
    "time": "Sun Dec 10 13:24:59 2023 -0700"
  },
  "committer": {
    "name": "Jeff Law",
    "email": "jeffreyalaw@gmail.com",
    "time": "Sun Dec 10 13:26:03 2023 -0700"
  },
  "message": "Improve performance of the H8 simulator\n\nRunning the H8 port through the GCC testsuite currently takes 4h 30m on my\nfastest server -- that\u0027s roughly 1.5hrs per multilib tested and many tests are\ndisabled for various reasons.\n\nTo put that 1.5hr/multilib in perspective, that\u0027s roughly 3X the time for other\nembedded targets.  Clearly something isn\u0027t working as well as it should.\n\nA bit of digging with perf shows that we\u0027re spending a crazy amount of time\ndecoding instructions in the H8 simulator.  It\u0027s not hard to see why --\nbasically we take a blob of instruction data, then try to match it to every\ninstruction in the H8 opcode table starting at the beginning.  That table has\n~8000 entries (each different addressing mode is considered a different\ninstruction in the table).\n\nNaturally my first thought was to sort the table and use a binary search to\nfind the right entry.  That\u0027s made excessively complex due to the encoding on\nthe H8.  Just getting the sort right would be much more complex than I\u0027d\nconsider advisable.\n\nAnother thought was to build a mapping to the right entry for all the\ninstructions that can be disambiguated based on the first nibble (4 bits) of\ninstruction data and a mapping for those which can be disambiguated based on\nthe first byte of instruction data.\n\nThat seemed feasible until I realized that the H8/SX did some truly horrid\nthings with encoding branches in the 0x4XYY opcode space.  It uses an \"always\nzero\" bit in the offset to encode new semantic information.  So we can\u0027t select\non just 0x4X.  Ugh!\n\nWe could always to a custom decoder.  I\u0027ve done several through the years, they\ncan be very fast.  But no way I can justify the time to do that.\n\nSo what I settled on was to first sort the opcode table by the first nibble,\nthen find the index of the first instruction for each nibble. Decoding uses\nthat index to start its search.  This cuts the overall build/test by more than\nhalf.\n\nNext I adjusted the sort so that instructions that are not available on the\ncurrent sub architecture are put at the end of the table.   This shaves another\n~15% off the total cycle time.\n\nThe net of the two changes is on my fastest server we\u0027ve gone from 4:30 to 1:40\nrunning the GCC testsuite.  Same test results before/after, of course.  It\u0027s\nstill not fast, but it\u0027s a hell of a lot better.\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "96254ea916d5c16b40195c58a7959f559668a0e8",
      "old_mode": 33188,
      "old_path": "sim/h8300/compile.c",
      "new_id": "51ad66df68106a63ebdec34134779d1db670abac",
      "new_mode": 33188,
      "new_path": "sim/h8300/compile.c"
    }
  ]
}