80 символов в строке и режим 512 точек вообще

[svofski]

ivagor, взял твою версию, пожульничал с ней -- 128 символов, четыре развертки, плюс убрал вычисление терминальной строки на каждый символ. Получилось 53 символа, почти 54 без самой тютельки. В первом сообщении обновил ссылку.

- - - Добавлено - - -

Получается в шрифте РДС на один символ 2560 / 256 = 10 байт, вполне нормально, даже с запасом на надстрочные и подстрочные "закорючки"... Надо посмотреть исходники РДС, как там символы кодируются.

Это да.. в смысле, что хранить так нормально, но для быстрого рисования это компромисс.

- - - Добавлено - - -

Upd: выстрадал тютельку, полных 54.

- - - Добавлено - - -

А если столбцами? Там можно кое-что выгадать, я думаю.

Особенно если рисовать, как делает Manwe, побитовыми столбцами.

Что такое побитовые столбцы? Тут в принципе и так столбцами, но не обязательно организованными наилучшим образом. Одна из проблем в том, что ширина текстовых колонок, если их 80 конечно, не кратна байтам.

[Sandro]

Что такое побитовые столбцы? Тут в принципе и так столбцами, но не обязательно организованными наилучшим образом. Одна из проблем в том, что ширина текстовых колонок, если их 80 конечно, не кратна байтам.

Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. То есть, маска бита на весь столбец фиксирована, м идём сверху вниз, сдвигая изображение стобца и по переносу определяя, закрашивать писель или нет. Т.е. символ хранится не горизонтально, а вертикально нарезанный. Выходит унифицированный код вместо зоопарка со сдвигом на 0/2/4/6 пикселя.

[KTSerg]

Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. ...

Получится значительно больше операций с памятью, а они медленные.
Или при горизонтальном выводе тоже каждый пиксель отдельно на экран выводится?
Подозреваю, что байт читается, дополняется текущей маской и сохраняется в экран. При высоте символа 8 пикселей, выходит в лучшем случае 16 чтений, 16 записей, в худшем 32/32. Если каждый пиксель выводить отдельно, то всегда 48 чтений, 48 записей.

[ivagor]

Немного капитанства. В рамках выбранного подхода осталось разве что добавить оставшиеся промежуточные предсдвиги (увеличить память под предсдвинутый фонт вдвое). Дальше уже только за счет стека. Там полный предсвдиг, а для x_6 и x_7 даже по 2 байта на строку, чтобы убрать "лишние" логические операции. Если не запрещать прерывания, то придется добавить по 2 байта между символами. Вычисление адреса буквы опять замедлится, рисование ускорится. "Нет худа без добра, сказала лиса, зато ты сможешь разместить предсдвинутые фонты в квазе". Смысл стековый вариант имеет, если выводить символы группами, один раз сохраняем sp, выводим группу (без вызовов процедур, только переходы), восстанавливаем sp.

[Sandro]

Получится значительно больше операций с памятью, а они медленные.

А сдвиги -- они быстрые? Ведь при горизонтальном выводе пиксели надо ещё и сдвигать. 16-разрядным сдвигом, поскольку они могут заехать в соседний байт. В худшем случае -- сдвигать на 4 бита. 32 16-разрядных сдвига. А так всего 48, по разу на пиксель, чтобы достать очередной бит.

Хотя, разумеется, можно завести таблицу на 512 байт и вращать через неё.

[KTSerg]

... разместить предсдвинутые фонты в квазе". ...

Во-во, распаковать предсдвинутые фонты на кваз, в файл. Его адрес (на квазе) сохранить для возможности прямого доступа, а не через файловую систему.

[Advertiser]

[svofski]

Побитовые столбцы и есть побитовые столбцы.
Так именно проблема некратности байтам и решается. Символ выводится однобитовыми столбцами. То есть, маска бита на весь столбец фиксирована, м идём сверху вниз, сдвигая изображение стобца и по переносу определяя, закрашивать писель или нет. Т.е. символ хранится не горизонтально, а вертикально нарезанный. Выходит унифицированный код вместо зоопарка со сдвигом на 0/2/4/6 пикселя.

Получается, что по одному пикселю за шаг мы закрашиваем? Это может быть удобно/интересно для компактного хранения, но точно не для быстрого рисования. Как упражнение можно будет попробовать, даром что фонт в моем примере изначально как раз лежит на боку.

- - - Добавлено - - -

Немного капитанства. В рамках выбранного подхода осталось разве что добавить оставшиеся промежуточные предсдвиги (увеличить память под предсдвинутый фонт вдвое). Дальше уже только за счет стека. Там полный предсвдиг, а для x_6 и x_7 даже по 2 байта на строку, чтобы убрать "лишние" логические операции. Если не запрещать прерывания, то придется добавить по 2 байта между символами. Вычисление адреса буквы опять замедлится, рисование ускорится. "Нет худа без добра, сказала лиса, зато ты сможешь разместить предсдвинутые фонты в квазе". Смысл стековый вариант имеет, если выводить символы группами, один раз сохраняем sp, выводим группу (без вызовов процедур, только переходы), восстанавливаем sp.

Предсдвиги здорово помогли для тех случаев, где было четыре и три сдвига. В текущем варианте третий предсдвиг дал очень мало. Для спорта тут все способы хороши, но для практики я думаю достаточно двух.

Со стеком я не очень понимаю как тут выгадаешь. Потому что ldax inr ldax inr -- это 32 такта, а pop mov mov -- это 28, 4*16 = 64 такта. Ухуху. Но на подготовку и восстановление затраты отнимут 60 тактов (если память не изменяет, может быть и хуже). 4 такта в лучшем случае, проще выпилить xchg там, где он остался от лени. Выгоду можно получить только если вынести подготовку-восстановление за скобку на все рисование строки, но тогда это совсем жесть и даже бенчмарк непонятно как тогда делать.

[ivagor]

Если говорим о простой пересылке (без логических операций), то без стека 32 такта/байт, как ты написал, а стеком pop mov inr mov inr - 22 такта/байт. При выводе 16 байт выигрыш 160 тактов и, как уже я написал, лучше сохранять стек один раз на группу символов, это здорово сэкономит время.

[svofski]

Если говорим о простой пересылке (без логических операций), то без стека 32 такта/байт, как ты написал, а стеком pop mov inr mov inr - 22 такта/байт. При выводе 16 байт выигрыш 160 тактов и, как уже я написал, лучше сохранять стек один раз на группу символов, это здорово сэкономит время.

Погоди, как так. Я тоже странно посчитал. Все зачеркиваем.

Для столбцов не разбитых на два:

Загрузка двух строк по ссылке: ldax \ inr \ ldax inr -- это 32 такта. Стеком две строки: pop mov mov = 12 + 16 = 28. Выгода 4. Это выгода на пару строк, то есть умножаем на 8 пар, итого -32.

Если столбцы разбиты на два, сразу для двух строк считаем. Загрузка по ссылке: ldax ldax inr ldax ldax inr = 48 тактов, стеком: pop mov mov mov mov = 44 такта. Опять то же самое, 4 выигрыш. Те же -32.

Как у тебя получились такие большие цифры?

[ivagor]

Я считал время простой (без дополнительных операций) пересылки (_x_0)
Без стека: ldax inr stax inr - 8+8+8+8=32 такта/байт
Стеком: pop mov inr mov inr - 12+8+8+8+8=44 такта/2 байта=22 такта/байт

- - - Добавлено - - -

Посчитаем время пересылки с OR для x_1 - x_5
Без стека: ldax inr ora mov inr - 8*5=40 тактов/байт
Стеком: pop mov ora mov inr mov ora mov inr - 12+8+4+8+8+8+4+8+8=68 тактов/2 байта=34 такта/байт, тут выигрыш меньше, 6 тактов/байт
Для x_6 - x_7 мне лень считать, если уж только это будет очень принципиально.