Спроектировать процессор «на коленке». Возможно ли?

dmitrik> В общем - да. Файл читается 1 раз.

Да хоть для 10 проходов файл можно один раз прочитать

zyxman>> В том и дело, что схема не перепроектируется.
zyxman>> Точнее речь о том, что для CISC такое можно исполнить без перепроектирования схемы (там просто делается другая маска для ПЗУ микрокоманд и получается отдельный степпинг), а в RISC уже конечно так не сделаешь.
Wyvern-2> Зачем? В х86 начиная с i586Pro это можно сделать программно - там флэш

Это не флэш:

Память не является постоянной и поэтому "загрузка микрокода" требуется при каждом включении/перезагрузке компьютера

 

Wyvern-2> Это не программная препроцессорная оболочка, как у Transmeta Crusoe

УУУ, как время летит!
- Лет 15 назад бы мне кто сказал про динамическую компиляцию (или JIT, ее еще называют) - сделал-бы большие глаза и "челюстью ушиб ногу"
А теперь это банальная "программная препроцессорная оболочка", которую даже любители делают в свободное время (см qemu).

Кстати, IBM такую технологию использует по полной программе - в ихних крайних мейнфреймах прога пишется под стандартную архитектуру и "на лету" перекомпилируется под конкретное железо.

Для Трансметы прелесть была в другом: заменив программой целый здоровенный блок процессора (у AMD хардварный транслятор из x86 в RISC, ЕМНИС больше 30% площади чипа), они еще на старой технологии, сумели в чип запихнуть шину и контроллер DRAM (весь северный мост и частично южный), и таким образом получилась дешевая система с приличной производительностью и со сверхнизким потреблением.
Кстати, производительность у Crusoe была не впечатляющая, потому что в системе на которую оно рассчитывалось, было заведомо мало памяти, а динамическая компиляция дает хорошую скорость как раз если многократно работает однократно перекомпиленный код, плюс нюансы, вроде того что Сони выпустившая ноут на Crusoe пожлобилась и поставила туда медленную ОЗУ (да, весьма вероятно что эплы смогли-бы этот проц использовать получше, но не срослось)..

zyxman> Кстати, производительность у Crusoe была не впечатляющая....(да, весьма вероятно что эплы смогли-бы этот проц использовать получше, но не срослось)..

Апплы, имея компилятор, могли бы свои ОС и прикладухи делать прямо в коде Крусое И получать оооффффигительную производительность, много выше. чем у Выньтела А ежели человек - лох, и хотел продолжать иметь дело с Мелкомягким софтом - пожалуйста, был бы эмулятор, с так себе производительностью.

dmitrik> Мой пойнт в том что прогресс не обязан идти от простого к сложному, часто получается наоборот.

+100
Тут все дело в том что возможности человеческого мозга ограничены, и слишком сложный инструмент, не будут полноценно использовать.

C++ был эксперимент. Интересный эксперимент, но неудачный, потому что язык очень усложнили а многого действительно нужного не добавили.
И сейчас, с опытом применения (с множеством сторонних подпорок), и с появлением альтернатив, конечно видно как можно переделать и почему, и конечно уже переделывают (Java, D), но это уже не C++ а другие языки и другие люди.

Wyvern-2> ( Были компы Аппле работающие с любым набором команд ...) а именно перепрограммирование собственно RISC команд

Эта идея хороша только для патента. А как до реального дела дойдёт, начнётся куча проблем. Начиная с того, что для каждой архитектуры есть такое понятие, как "хазард", особое сочетание команд, которые учитывает компилятор. Например, после записи в сопроцессор нужно вставить пару-тройку нопов и только потом читать. И это самый простой хазард, а так набирается немерянная куча таких мелочей, в итоге работоспособность на таком универсальном ядре всех программ не гарантируется никак, а уж тем более - с любым набором.

Mishka> Чего по простому-то? Алгол 68 задумывался специально с полным оверлоадом всех операций...
Есть ещё один зверский в этом смысле язык - PL/I.

Mishka>> Чего по простому-то? Алгол 68 задумывался специально с полным оверлоадом всех операций...
pokos> Есть ещё один зверский в этом смысле язык - PL/I.

А что могут подумать о Форте? (гусаров попрошу помолчать )

И все-же фигня оверлоад.
Давайте подумаем реально, чего не достает современным языкам, ну хотя-бы посмотрев чего делается вручную.
Итак:
1. юнит-тесты - какого, извините, почти во всех языках не предусмотрено элементарно указывать допустимый диапазон входных значений для функции/параметров объекта?
- да, это в приличных языках можно встроить в код (через тот-же оверлоад), но проверка/модификация этих надстроек нетехнологична.
2. Это скорее первое, но слишком абстрактно: зачем вообще созданы ЯВУ? - они созданы чтобы можно было абстрагироваться от железа. И что мы видим реально?
- Опять-же, оверлоад это тру, он позволяет хорошо-так, с размахом, "растечься мыслию по древу", но требуется двойная работа, ибо потом этот код нужно документировать и естественно люди совершают ошибки в данном процессе, а многие вообще на него забивают..

Ведь до чего дожили - появились системы, использующие технологии ИИ, чтобы разобрать код написанный на C++!
Люди! Ау! Мы явно идем не туда!

dmitrik> В общем - да. Файл читается 1 раз. Про циклические инклуды можно спорить - типа "компилятор не виноват, программист так захотел", "на месте этого файла мог быть другой" и пр. Но я не настаиваю. Главное что код генерится с первого прочтения.


Нет. Спорить не надо — я компиляторщик по образованию. И реальные писал. В том же Алголе 68 принимал участие. Однопроходный — это когда одного прохода хватает на всё, в том числе и на определение циклов.

dmitrik> Ну дык никто не спорит, "Алгол был настолько впереди своего времени, что он был лучше не только своих предшественников но и почти всех своих последователей" ©. Но для того времени Алгол был слишком сложен в реализации и потому тормозил развитие новых архитектур. Мой пойнт в том что прогресс не обязан идти от простого к сложному, часто получается наоборот.

Ы? Тормозила развитие архитектур? То-то, мы его сделали и на ЕС-ку, и на персоналки, и на PDP-11, и на Самсон, и на ПС-1001, а потом ещё и объединять с Адой и Модулой-2 начали. Правда, не закончили. И С++ с Джавой отнюдь языки не простые. Как и многие функциональные языки.

Mishka>> Чего по простому-то? Алгол 68 задумывался специально с полным оверлоадом всех операций...
pokos> Есть ещё один зверский в этом смысле язык - PL/I.
Здесь не сам язык зверский. Здесь описание зверское — которое венское. Пересмотренное сообщение об Алголе 68 с полным английским и русскими текстатм — страниц 300. И весь язык описан. А венское описание — более 3,000 страниц. Ну и правил преобразования там до фигушки. И лозунг при разработке был — если можно найти хоть какой-то смысл из той программы, что на входе — его и ищем!

Mishka> Здесь не сам язык зверский. Здесь описание зверское — которое венское. ...
Я с PL/I пытался ознакомиться (не учить - какое там!) и быстро обломался, ибо моск на полку, а на практике он мне не был нужен.

Mishka>> Здесь не сам язык зверский. Здесь описание зверское — которое венское. ...
pokos> Я с PL/I пытался ознакомиться (не учить - какое там!) и быстро обломался, ибо моск на полку, а на практике он мне не был нужен.

Ты с Прологом ты(покос), пойди туда(не зная куда)|принеси то(не зная что) или Лиспом (((((((((())))))))))(найди ошибку ) знаком? Ну, а про VHDL вааще не говори, о нем все сказано: такое извращение, что аж приятно

Wyvern-2> а про VHDL вааще не говори, о нем все сказано: такое извращение, что аж приятно

А что может быть извращенного в подмножестве Ады?

dmitrik>> Ну дык никто не спорит, "Алгол был настолько впереди своего времени, что он был лучше не только своих предшественников но и почти всех своих последователей" ©. Но для того времени Алгол был слишком сложен в реализации и потому тормозил развитие новых архитектур. Мой пойнт в том что прогресс не обязан идти от простого к сложному, часто получается наоборот.
Mishka> Ы? Тормозила развитие архитектур? То-то, мы его сделали и на ЕС-ку, и на персоналки, и на PDP-11, и на Самсон, и на ПС-1001, а потом ещё и объединять с Адой и Модулой-2 начали. Правда, не закончили.
Пардон, а о каком периоде времени идет речь? Я-то имел в виду 197х - появление C, Unix и RISC. И, насколько я знаю, в то время сделать язык и ОС для новой архитектуры была проблема и появление C/Unix сильно облегчило жизнь. И еще, а на чем вы его писали если не секрет? У вас был кросс-компилятор Алгола на Алголе?

Mishka> И С++ с Джавой отнюдь языки не простые. Как и многие функциональные языки.
Дык опять же никто не спорит, только это совсем другая геологическая эпоха

Wyvern-2> Ты с Прологом ты(покос), пойди туда(не зная куда)|принеси то(не зная что) или Лиспом (((((((((())))))))))(найди ошибку ) знаком?
И не говори, кум. Лиспом баловался студентом-первокуром. Нихрена уже не помню вообще. Даже из Форта что-то ещё помню...а вот Лисп вискочил совсем.
Wyvern-2> Ну, а про VHDL вааще не говори, о нем все сказано: такое извращение, что аж приятно
Язык как язык.

Wyvern-2>> Ну, а про VHDL вааще не говори, о нем все сказано: такое извращение, что аж приятно
pokos> Язык как язык.
VHDL как язык - старомоден и кривоват. А главное - все его навороты совершенно не нужны для тех целей для которых он применяется, и наоборот, только мешают. Не далее как вчера мне пришлось убрать из кода все RECORD-ы По алгоритму мне нужен был стек (массив) записей. ModelSim это ниасиливал и откровенно врал в стиле 2х2=5 - народ подходил, смотрел и офигевал. Пришлось вместо этого заводить кучу отдельных массивов - прям как в детстве на Бейсике. Ну какой же это в #опу язык высокого уровня в котором массив записей не работает
Еще для любителей VHDL пара простеньких задачек из жизни:
1. Проиндексировать массив из двух элементов сигналом типа std_logic.
2. В одном месте кучу разнообразных сигналов соединить в один вектор,а в другом месте аналогичным образом разложить обратно. (на верилоге: xi = {ai,bi,ci}; .... {ao,bo,co} = xo; )
Флаг в руки

Mishka>> Здесь не сам язык зверский. Здесь описание зверское — которое венское. ...
pokos> Я с PL/I пытался ознакомиться (не учить - какое там!) и быстро обломался, ибо моск на полку, а на практике он мне не был нужен.

Да, вообщем-то, без проблем — на втором курсе нам дали его.

dmitrik> VHDL как язык - старомоден и кривоват. А главное - все его навороты совершенно не нужны для тех целей для которых он применяется, и наоборот, только мешают. Не далее как вчера мне пришлось убрать из кода все RECORD-ы По алгоритму мне нужен был стек (массив) записей. ModelSim это ниасиливал и откровенно врал в стиле 2х2=5 - народ подходил, смотрел и офигевал.

А массив разве не generate делается? А Verilog Не пробовали? Он всё ж без лишних наворотов.

Wyvern-2> Ты с Прологом ты(покос), пойди туда(не зная куда)|принеси то(не зная что) или Лиспом (((((((((())))))))))(найди ошибку ) знаком? Ну, а про VHDL вааще не говори, о нем все сказано: такое извращение, что аж приятно


А что в Прологе такого сложного? Просто, ты видимо, алгебру предикатов не учил.

dmitrik> Пардон, а о каком периоде времени идет речь? Я-то имел в виду 197х - появление C, Unix и RISC. И, насколько я знаю, в то время сделать язык и ОС для новой архитектуры была проблема и появление C/Unix сильно облегчило жизнь. И еще, а на чем вы его писали если не секрет? У вас был кросс-компилятор Алгола на Алголе?

Ну, имплементация Algol 60 и Algol W — это 60-е.

До RISC-ов были mainframe-ы — и не только IBM. А так же малые машины.

C/Unix — да, облегчело жизнь. Но первые книжки по переносимости софта появились уже тогда. Не только для С.


Для Алгола 68 у нас всё было написано на Алголе 68. Было несколько проходов с ПЯ между ними.
Лексический, Синтаксический, Высокоуровневая Оптимизация (опциональная фича), Генерации Кода с низкоуровневым оптимизатором. Поэтому перенос компилятора заключался в разработке проекций и написании генератора кода. Впрочем, наши Адики так же сделали — одна школа. А потом уже мы попытались составить достаточно общие ПЯ, чтобы Ада, Паскаль, Модула 2, Алгол 68 и даже (страшно подумать) С++ можно было в них откомпилировать, а проходы, которые ниже Синтаксического были бы общими.

Первый компилятор с Алгола 68 сделала команда Цейтина-Терехова. Первый босс моего босса, а второй — мой босс. Насколько я знаю, никто больше Алгол 68 в СССР и не сделал. Хотя в разработке и обсуждении стандарта принимали участие Лавров, Рар, Ершов, Берс. Потосин ещё кажеться. Потом новосибирцы ушли и в другие языки и говорили Андрею, что того заклинило на статических языках. А он говорил новосибирцам, что те ни хрена не понимают в колбасных обрезках. Писали его сначала во многом на ассемблере. Но по ходу переписывали и на сам Алгол 68. Если мама не выбросила ленточки, то дома в Кишинёве должны валятся ленточки со всеми исходниками.



dmitrik> Дык опять же никто не спорит, только это совсем другая геологическая эпоха

LISP? Simula 67? Опять-таки, немного позже, но работы Вирта по Лилит.

Серокой> А массив разве не generate делается?
Массив это array. У меня было что-то типа:
type STACK_ENTRY_TYPE is record ... end record;
type STACK_TYPE is array(0 to N-1) of STACK_ENTRY_TYPE;
signal stack : STACK_TYPE;
Проблема похоже была в том что для 2х первых элементов поля присваивались отдельно, каждое в своем процессе, а остаток стека сдвигался одним махом stack(2..N-1) <= stack(1..N-2)

Серокой> А Verilog Не пробовали? Он всё ж без лишних наворотов.
Пробовал Клиенту нужен VHDL.

Wyvern-2>> Ты с Прологом ты(покос), пойди туда(не зная куда)|принеси то(не зная что) или Лиспом (((((((((())))))))))(найди ошибку ) знаком? Ну, а про VHDL вааще не говори, о нем все сказано: такое извращение, что аж приятно
Mishka> А что в Прологе такого сложного? Просто, ты видимо, алгебру предикатов не учил.

Я еще много каких алгебр не учил (и ты, кстати, тоже ) и это не повод для нейрофагии

Серокой>> А массив разве не generate делается?
dmitrik> Массив это array. У меня было что-то типа:....
Серокой>> А Verilog Не пробовали? Он всё ж без лишних наворотов.
dmitrik> Пробовал Клиенту нужен VHDL.

А про ТРИ модели ты в курсе?

Wyvern-2> Я еще много каких алгебр не учил (и ты, кстати, тоже ) и это не повод для нейрофагии
Алгебр в точности счётное множество.

Wyvern-2> А про ТРИ модели ты в курсе?
Поясните что вы имеете в виду, а то на ум ничего не приходит. Может быть трудности перевода а может быть и пробел в образовании, всяко бывает

Mishka> Для Алгола 68 у нас всё было написано на Алголе 68. [...]
Спасибо, было интересно узнать.

zyxman> А что могут подумать о Форте? (гусаров попрошу помолчать )

Как написал Дийкстра в известном письме: "Форт — это язык будущего для программистов прошлого."

zyxman> И все-же фигня оверлоад.

Нет, не фигня. Позволяет нормально описывать языки прикладного уровня. У нас создали систему для микрокодирования. На базе Алгола 68. Полностью систему команд народ переписывал за 3-5 дней.

zyxman> Давайте подумаем реально, чего не достает современным языкам, ну хотя-бы посмотрев чего делается вручную.
zyxman> Итак:
zyxman> 1. юнит-тесты - какого, извините, почти во всех языках не предусмотрено элементарно указывать допустимый диапазон входных значений для функции/параметров объекта?

Учить историю надо. Хотя бы Аду или Модулу 2. А юнит тесты, пардон за тривиальность, это проверка не синтатсиса, а семантики. И поддержка их есть у всех — тот же код. А программки за тебя писать по анализу язык не сможет. Тут явно смешал ты несколько проблем в одну кучу.

zyxman> - да, это в приличных языках можно встроить в код (через тот-же оверлоад), но проверка/модификация этих надстроек нетехнологична.

Ы?

zyxman> 2. Это скорее первое, но слишком абстрактно: зачем вообще созданы ЯВУ? - они созданы чтобы можно было абстрагироваться от железа. И что мы видим реально?

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


zyxman> - Опять-же, оверлоад это тру, он позволяет хорошо-так, с размахом, "растечься мыслию по древу", но требуется двойная работа, ибо потом этот код нужно документировать и естественно люди совершают ошибки в данном процессе, а многие вообще на него забивают..

Ты забываешь ещё одну особенность перегрузки — порядок выполнения операций. В Алголе 68 можно было его задать указав приоритет выполнения операции — от 0 до 9. Но тут проблема такая же, как и с библиотеками — своя область применения. Соответственно, внутри будет своя терминология, свои принятые соглашения.

zyxman> Ведь до чего дожили - появились системы, использующие технологии ИИ, чтобы разобрать код написанный на C++!
zyxman> Люди! Ау! Мы явно идем не туда!

Туда-туда. Просто код на С++ хоть как-то формализован. А потуги на универсальность — сначала код на С++, потом ...