Quote (KOE) |
Видимо, ты ничего не делаешь. Это ты ничего не делаешь, только болтовню разводишь. А я разрабатываю и делаю реальное ZX железо. |
А я реальное ZX железо не разрабатываю. Но на документированные и нет баги в микроконтроллерах и компиляторах нарываюсь регулярно. И не утверждаю, что вот мол XXX абсолютно безглючно, особенно если на сайте уже ерратов выложили 5 лет назад и в те же времена примерно не рекомендовали к использованию, тем более что есть в несколько раз более доступная, дешёвая, и безглючная замена. Да и вообще ни одного идельно безглючного mcu припомнить не могу. Специфические проблемы везде и вляпаться в них, если не читать заранее, элементарно.
Quote (KOE) |
а спеке -- есть. Насколько может быть нормальный компилятор в столь ограниченных условиях. 1985 год. Фирма HiTech software. Бля... Напиши на этом долбокомпиляторе процедуру вывода спрайтов и выложи ее сюда. Если не напишешь - все вышесказанное я считаю пустой болтовней. |
Я "на слабо" ничего делать не буду. Не пацан.
Общий принцип пояснить могу (не тебе -- тебе, я понял, бесполезно, но здесь есть читающие люди). Многие "низкоуровневые" процедуры под конкретную платформу пишутся таки руками на ассемблере. Например функции работы со строками, в стандартной библиотеке (string.h) часто реализуются на ассемблере потому, что непосредственно из C не доступны векторные инструкции, например. Но это не означает что более высокоуровневые функции имеет какой-то смысл переписывать на ассемблере. Также и здесь. Спрайт в позицию кратную знакоместу можно вывести банально серией memcpy() в цикле, если речь идёт о спектрумовской структуре экрана. По производительности оно не в разы будет уступать ассемблерному варианту. Если нужно отсечение по маске и сдвиг на позицию не кратную знакоместу, обычно подготавливают ряд спрайтов
заранее сдвинутых на разное число разрядов -- процедура тривиальна и её описывать смысла нет. Вывод с отсечением по маске функциями стандартной библиотеки уже вызывает сложности. Оптимальным в отношении быстродействие/трудоёмкость(и универсальность, возможность переноса на другую платформу) будет создание функции написанной на ассемблере, подобной memcpy, например mask_vector(char *dest, const char *mask, const char *src), которая для каждого байта векторов dest, mask и src выполняет операцию *dest++=*dest&*mask++|*src++. Несложно понять, что большая часть тактов ЦПУ будет потрачена в данной функции и неэффективность (раза в 2 приблизительно) остальной части программы существнного вклада в функцию вывода спрайтов не внесёт. Разумеется, речь не идёт об супероптимизированной функции с выводом через стек и чем-то подобным. Высокая эффективность, КПД 99.9%, обычно достигается ценой исключительно высоких, неприемлемых чаще, затрат. Хотя
динамическую генерацию кода (для вывода спрайта последовательностью инструкций вида LD HL, XXX: PUSH HL...) никто не запрещает делать хоть на бейсике. Примерно 200% затраты объёма кода и ЦПУ против ассемблерной версии -- это практический результат. И думаю, он того В РЕАЛЬНОЙ ЖИЗНИ стоит. Разумеется, это не исключает использования ассемблера в каких-то исключительно узких местах -- но только в этих местах. Типовой пример -- стартап к C-программе без ассемблера просто невозможен чаще.
Отдельный ньюанс в споре C vs Assembler -- распределение памяти. В сколько-нибудь большой и сложной программе "нужен ватман размером с комнату" (c). Что C-компилятор осуществляет автоматически. Особенно актуально в случае когда на целевой архитектуре стек программно не доступен (тот же microchip pic) и все переменные, по факту, распределяются статически. Строить дерево вызова функций руками? Нет, да на том же Z80. Можно всё объявить static. Так даже код быстрей получится. И плевать даже на возможность рекурсивных вызовов. Но /объём памяти/ затраченный под переменные при таком распределении В РАЗЫ превышает реально требуемый. Это просто факт. Что характерно у многих кто пытается писать большие программы на ассемблере под ZX-Spectrum остро встаёт проблема нехватки памяти. Просто потому, что вся память распределена статически и выделена независимо от того, используется она в данный момент или нет.
Quote (KOE) |
Не надо менять местами причину и следствие. То что не производятся расширенные варианты -- это следствие. Это следствие. Но причина - другая (не нерасширяемость архитектуры). Просто творческую работу в Ангстреме никто не финансирует. |
Объясни как конкретно в "Тесее" можно расширить память программ или данных. При том, что под поля адреса в КОПах жёстко выделены определённые разряды и они как бы уже полностью используются. Банками, а-ля спектрум? Или как под "Тесей" можно написать C-компилятор с такой архитектурой? В садъ, не нужен? "Потребности в колбасе нет" (c) Можно конечно внушать себе это бесконечно долго, но весь мир куда-то в другом, противоположном направлении двигается, туда где потребность в колбасе чаще есть и даже как-то удовлетворяется.