Здравствуйте, 0x7be, Вы писали:

0>Странное решение. Разве это не должно приводить к тому, что команда, использующая АЛУ, будет выполняться дольше, т.к. нельзя будет одновременно считать арифметику для команды и сдвигать IP?
Перечитал доку — нет, там отдельный сумматор для инкремента. "Общий" АЛУ был только на прототипе.

0>Её сложнее проектировать и эволюционировать. Насколько я знаю, как только методы синтеза схем стали выдавать нормальные результаты, с ручной разводкой схем быстро завязали.
ЕМНИП Интел только в P-4 перешла на синтез. Просто железки обычно не разрабатывают по принципу "а давайте-ка мы как-нить сбоку вот эту фичу прикрутим". Если сразу сделать структурную схему девайса, то всё остальное будет проще.

0>Не хватает ещё синтаксического сахару для поддержки конечных автоматов (по типу как это сделано в методах-итераторах в C#).
Железячники вообще товарищи консервативные — ну типа как жабники

0>Есть немного, но у меня пока такая ситуация, что я больше думаю, чем пишу
На самом деле писать-то в ИДЕ почти пофигу, а вот читать лично мне сложнее, потому что содержательная часть кода теряется в куче бойлерплейта. Особенно бесит COMPONENT->PORT MAP — чистое дублирование кода, и часть COMPONENT вообще можно выбросить, т.к. в PORT MAP можно использовать синтаксис pin => signal. В верилоге это намного более элегантно сделано (синтаксически почти как в С++/С#). Ну и тест-бенчи ИМХО в верилоге проще (==быстрее) писать, что важно, т.к. мало кому нравится писать юнит-тесты

0>Там интерфейс попроще будет, чем VGA. Впрочем, у меня VGA-адаптер со знакогенерацией занимает две страницы на VHDL. Правда, там есть какие-то особенности реализации, которые я так и не понял.
Абсолютно то же самое один-в-один — только частота у LCD-панели у каждой своя (впрочем, многие панели не очень разборчивы, и будут работать в широком диапазоне частот развёртки). Ибо все современные видеопротоколы фундаментально одинаковы (из-за обратной совместимости — это ещё один "пунктик" у железячников )
Правда в твоём случае ещё нужен знакогенератор (т.к. ты пишешь в текстовом режиме как я понял), что несколько усложняет дело. Если бы использовал графический режим — то было бы то же самое с точностью до разрешения, размеров внеэкранных областей и частоты развёртки.

0>Это вообще пока моя беда — некоторые вещи у меня работают вот так, а не иначе, и я не понимаю, почему вот так оно работает, а иначе — нет.
Ну дык выкладывай код и спрашивай — чем смогу, помогу. Как оказалось, я весьма неплохо всё помню с универа несмотря на то, что прошло 10 лет

0>SRAM-фигня, SDRAM веселее Разница в сложности между прямолинейной и оптимизированной реализациями раз в десять
Там SDRAM и демонстрируется — я не так написал. Товарищ авалоноский контроллер юзает. На моей девплате тоже SDRAM стоит, но в конечном девайсе мне нужно нечто побыстрее 100 МГц, так что думаю использовать DDR2/3 (тут рядом как раз тема об этом).

0>P.S. А вообще я сейчас занят переписыванием ассемблера с VBA на C# Думаю, что надо будет подумать о портировании какого-нибудь простенького С-компилятора на свою архитектуру.
Возьми какой-нить flex/bison/yacc ну или что там сейчас модно юзать для создания парсеров. Мы в универе за две пары на лабах успевали полнофункциональный парсер С сделать Кодогенератор тоже относительно просто сделать, если забить на оптимизацию. Основная сложность там — это портирование/написание crt. Вот с ней возни будет много.

P.S. Ты бы кстати в блог почаще писал о прогрессе — интересно же, как там у тебя процесс идёт, какие грабли попадаются, ну и т. д.