Отправлено SM 19 июля 2005 г. 16:05 В ответ на: а если вообще команды энтропийно кодировать (то есть - если ADD R0,R1 встречается чаще чем ADD R2,R3, то почему они должны иметь равную длину?) отправлено yes 19 июля 2005 г. 15:25

чтобы декодер инструкций монстром не стал. То есть чтобы длину команды и код операции можно было относительно просто получить из старших (если big endian) битов кода команды. При этом приблизиться к оптимальному кодированию. Только вот зачем что-то еще мапировать? Это можно конечно, но зачем? То есть грубо говоря сделать предекодер загружаемым... У меня предекодер как раз и разбирает код переменной длины в поля постоянной длины (включая и длину инструкции) для дальнейшей обработки. Получается надо всунуть мини-FPGA туды заместо предекодера? Но что это даст? Допустим если и по скорости и по площади позволительно будет.

А вот насчет кода x86 - я бы его не назвал "моим подходом" с 8-битной кратностью. Там из-за совместимости со старыми 8086 совсем кодирование далеко от оптимального вышло.

• тьфу - хотел про 86 сказать - там весьма оптимально - есть префикс, который переводит в 32 — yes   (19.07.2005 16:31 194.133.69.2, 225 байт)
  • Да я не про префикс (+) — SM   (19.07.2005 16:36 195.225.131.183, 295 байт)
• ну а тогда закодировать по Хаффману (как ВН предлагал, только вряд ли будет 1комада больше 50% кода) — yes   (19.07.2005 16:26 194.133.69.2, 398 байт)
  • Ответ: (+) — SM   (19.07.2005 16:34 195.225.131.183, 481 байт)
    • если процессор для себя, то и программы известные — yes   (19.07.2005 16:50 194.133.69.2, 741 байт)
      • Ответ: (+) — SM   (19.07.2005 16:59 195.225.131.183, 490 байт)
        • да я 51-е ненавижу даже больше чем 55-е (хотя еще в институте их програмил за деньги) — yes   (19.07.2005 17:13 194.133.69.2, 264 байт)
          • Ну как куда катится (+) — SM   (19.07.2005 17:19 195.225.131.183, 110 байт)