DF DF ; ( (
79 28 C1 ; (double)dx
6F 66 C2 ; )abs
13 10 C1 ; (long)Le
16 52 09 D4 FF ; )LONG;
; equal -> long Le = (long)abs((double)dx);
Процессоры будущего
Какой может быть технологий процессоров в будущем? Дешифраторов кода?
Давайте на время забудем о линейках Intel и других. Попытаемся представить этот процессор и принцип его работы. К примеру, обычный PIC:
1) Нет машинного кода; Программа представляется сжатыми строчками, которые при открытии в редакторе преобразуются в читабильный, символьный вид (add, mov); Все операции читаются и выполняются за такт и быстрее;
2) Код может быть как простым, так и сорсным; Сорсный код имеет комментарии и названия к меткам/переменным; Отчистив от них, получаем уже не опенсорс;
3) Вместо машинного кода - теги, указывающие, что данные нужно обрабатывать как шестнадцатиричное, десятичное, имя метки или как инструкцию; Тем самым в редакторе всё отображается соответствующе;
Это - поверхностный набросок...
Имеется JS-версия декодера, преобразующего код в текст. Область применения пока не найдена. Вот фрагмент кода:
16 байтов описывают операции высокого уровня.
Код разрабатывался так, чтобы достичь две цели: Как можно более высокий уровень (не ассемблер с машинным кодом) с формулами; И максимальную простоту, чтобы относительно легко построить на ПЛИС.
Цель: Не разработка конкурентно способного устройства, а исследование возможностей альтернативных подходов.
Буду рад, если кто-нибудь поможет ссылкой на исследовательский сайт или т.п., где можно выставить идею на анализ...
Спасибо за критику! Просто без критики не видно изъянов...
Давайте на время забудем о линейках Intel и других. Попытаемся представить этот процессор и принцип его работы. К примеру, обычный PIC:
1) Нет машинного кода; Программа представляется сжатыми строчками, которые при открытии в редакторе преобразуются в читабильный, символьный вид (add, mov); Все операции читаются и выполняются за такт и быстрее;
2) Код может быть как простым, так и сорсным; Сорсный код имеет комментарии и названия к меткам/переменным; Отчистив от них, получаем уже не опенсорс;
3) Вместо машинного кода - теги, указывающие, что данные нужно обрабатывать как шестнадцатиричное, десятичное, имя метки или как инструкцию; Тем самым в редакторе всё отображается соответствующе;
Это - поверхностный набросок...
Имеется JS-версия декодера, преобразующего код в текст. Область применения пока не найдена. Вот фрагмент кода:
Код:
Код разрабатывался так, чтобы достичь две цели: Как можно более высокий уровень (не ассемблер с машинным кодом) с формулами; И максимальную простоту, чтобы относительно легко построить на ПЛИС.
Цель: Не разработка конкурентно способного устройства, а исследование возможностей альтернативных подходов.
Буду рад, если кто-нибудь поможет ссылкой на исследовательский сайт или т.п., где можно выставить идею на анализ...
Спасибо за критику! Просто без критики не видно изъянов...
1) Если нет машины то нет машинного кода. Если есть машина есть и код. Что значит все команды? это фонтастика.
2) Это уже есть. Джава и нет.
Ближайшее будущее. Будет построенна машина на квантовых эфектах. Снижение энергии потребление до 10ват(уже есть но дорого, а будет повсеместно) увелечение частоты. Многоядерность.
Среднее/дальнее будущее будет построин квантовый компьютер. Но не полноценный. Из за физических ограничений его разрешающая способность будет ограниченна. Это значит что блок информации после декодирования будет вычисляться мнгновенно. Но размерность блока и сложность опираций будет ограниченна. Машина будет у каждого собственная настроенная на него сомово. Тем самым сможет предугадывать действи и желания пользователя. Плюс развитие ие что позволит общяться с ней как с человеком. Так как такая машина будет всегда при человеке то они образуют симбиоз ИИ и ЕИ. Что позволит по сути расширить человеческии возможности. Ограничения будут. Человеку придеться вводить команды. Но компьютер будет понимать их с полу слова. Конечно доказывать теоремы он не сможет. Только предоставлять информации в нужном виде.
2) Это уже есть. Джава и нет.
Ближайшее будущее. Будет построенна машина на квантовых эфектах. Снижение энергии потребление до 10ват(уже есть но дорого, а будет повсеместно) увелечение частоты. Многоядерность.
Среднее/дальнее будущее будет построин квантовый компьютер. Но не полноценный. Из за физических ограничений его разрешающая способность будет ограниченна. Это значит что блок информации после декодирования будет вычисляться мнгновенно. Но размерность блока и сложность опираций будет ограниченна. Машина будет у каждого собственная настроенная на него сомово. Тем самым сможет предугадывать действи и желания пользователя. Плюс развитие ие что позволит общяться с ней как с человеком. Так как такая машина будет всегда при человеке то они образуют симбиоз ИИ и ЕИ. Что позволит по сути расширить человеческии возможности. Ограничения будут. Человеку придеться вводить команды. Но компьютер будет понимать их с полу слова. Конечно доказывать теоремы он не сможет. Только предоставлять информации в нужном виде.
мне, пожалуйста, сдайте адрес диллера? тоже такую траву хочу
По всем трем позициям опроса - нет.
Правильно - "Детский лепет".
Фразы не лишены смысла, поэтому рассматривать это как бред - нельзя. В то же время указываются исключительно несущественные внешние признаки, которые никак не влияют ни на архитектуру, ни на принципы построения вычислительных систем. Поэтому всерьез рассматривать эти утверждения также нельзя.
Правильно - "Детский лепет".
Фразы не лишены смысла, поэтому рассматривать это как бред - нельзя. В то же время указываются исключительно несущественные внешние признаки, которые никак не влияют ни на архитектуру, ни на принципы построения вычислительных систем. Поэтому всерьез рассматривать эти утверждения также нельзя.
Цитата: andriano
По всем трем позициям опроса - нет.
Правильно - "Детский лепет".
Правильно - "Детский лепет".
Согласен. :)
Иногда люблю отвлечься от работы и заняться головоломками.
Ведь можно же в кодинге и процессоростроении найти интересные лазейки, где ещё никто не был лет так 60...
Ну, данное здесь - процессором назвать сложно. Просто, распределитель данных высокого уровня. Думаю, можно применить, например, в звуковых карточках для описания огибающих. Самое интересное то, что аппаратно он легко реализуется. :)
И всё таки. Существуют ли сайты, где такие идеи собирают и обсуждают? ;)
Vertecs
машинный код это еще не самый низкий код .
по аналогии атом названый "неделимым"- делится .
ниже его это микрокод . Там уже нет байтов и он не упорядочен . Тем более современные процессоры это уже десяток автономных устройств со своими задачами и программами . Это почти целый компьютер .
Теперь про однокристалки . Они в последнее совершили большой скачок вперед . Но вот системы для создания программ уже начали отставать . Хотя всегда было так . Только системы проектирования подтягиваются - людям надо еще больше .
Поэтому надо просто делать даже не Си подобным ,а С++ подобным .
Типа ассемблер с классами . По любому что то подобное надо будет городить . (ассемблер с классами ) компилирует в (ассемблер) а потом в код . Код кидается уже в процессор . Все надо автоматизировать . Писать #include - файлы для однокристалок . Так что есть что менять не трогая технологию проектирования и изготовления процессоров.
машинный код это еще не самый низкий код .
по аналогии атом названый "неделимым"- делится .
ниже его это микрокод . Там уже нет байтов и он не упорядочен . Тем более современные процессоры это уже десяток автономных устройств со своими задачами и программами . Это почти целый компьютер .
Теперь про однокристалки . Они в последнее совершили большой скачок вперед . Но вот системы для создания программ уже начали отставать . Хотя всегда было так . Только системы проектирования подтягиваются - людям надо еще больше .
Поэтому надо просто делать даже не Си подобным ,а С++ подобным .
Типа ассемблер с классами . По любому что то подобное надо будет городить . (ассемблер с классами ) компилирует в (ассемблер) а потом в код . Код кидается уже в процессор . Все надо автоматизировать . Писать #include - файлы для однокристалок . Так что есть что менять не трогая технологию проектирования и изготовления процессоров.
Может ли автор темы ответить на вопрос, чем отличаются CISC-процессоры от RISC-процессоров?
Какой тип процессоров PIC-контроллеров? Какой тип процессорову Intel и AMD (у старых, у новых)?
Надеюсь, автор все это знает, но все же дам ссылки на эти темы:
http://ru.wikipedia.org/wiki/CISC
http://ru.wikipedia.org/wiki/RISC
Какой тип процессоров PIC-контроллеров? Какой тип процессорову Intel и AMD (у старых, у новых)?
Надеюсь, автор все это знает, но все же дам ссылки на эти темы:
http://ru.wikipedia.org/wiki/CISC
http://ru.wikipedia.org/wiki/RISC
Kogrom
вот ты мне ответь : почему появились CISC если они такие "медленные" ?
Почему RISC тоже не стали полностью доминировать ?
На то что ты намекаешь верно?
Но самым "сдерживающим" фактором развития процессоров являются люди . И надо создавать мощную систему позволяющую разделить мир процессоров и мир людей , сохраняя при этом тесную связь процессора и человека.
А делать процессороподобный язык для людей и человекоподобный язык для процессоров не есть хорошо .
А автору темы лучше внимательнее изучать материал . Иначе тема может выродиться в юмор или флуд ,если так это автор и хочет.
вот ты мне ответь : почему появились CISC если они такие "медленные" ?
Почему RISC тоже не стали полностью доминировать ?
На то что ты намекаешь верно?
Но самым "сдерживающим" фактором развития процессоров являются люди . И надо создавать мощную систему позволяющую разделить мир процессоров и мир людей , сохраняя при этом тесную связь процессора и человека.
А делать процессороподобный язык для людей и человекоподобный язык для процессоров не есть хорошо .
А автору темы лучше внимательнее изучать материал . Иначе тема может выродиться в юмор или флуд ,если так это автор и хочет.
Цитата: qwone
Kogrom
вот ты мне ответь : почему появились CISC если они такие "медленные" ?
Почему RISC тоже не стали полностью доминировать ?
На то что ты намекаешь верно?
Но самым "сдерживающим" фактором развития процессоров являются люди...
вот ты мне ответь : почему появились CISC если они такие "медленные" ?
Почему RISC тоже не стали полностью доминировать ?
На то что ты намекаешь верно?
Но самым "сдерживающим" фактором развития процессоров являются люди...
1. Вероятно, потому что CISC появились раньше. А раньше они появились наверно потому, что их язык ближе к человеческому, или потому, что не было статистики, какие команды используются чаще всего.
2. Думаю RISC все же стали доминировать. CISC остались там, где требуется совместимость со старыми программами. Хотя могу ошибаться.
3. Я намекаю на то, что трудно сейчас выдумать что-то новое... но надо стараться :)
4. Про людей ничего не могу сказать. Плохо в них разбираюсь.
Цитата: squirL
мне, пожалуйста, сдайте адрес диллера? тоже такую траву хочу
+1
Господа, всех тут унесло в такие далекие дали, мне даже стало обидно, что я остался без такой убойной дури, поделитесь, где достать? Пожалуйста... :rolleyes:
Цитата: Ramon
Господа, всех тут унесло в такие далекие дали, мне даже стало обидно, что я остался без такой убойной дури, поделитесь, где достать? Пожалуйста... :rolleyes:
Я не пью, не курю, не наркоманю. Но заметил, что в пьяной компании сам себя веду как пьяный. Так же и тут. Хотя я еще сдерживаюсь :)
С другой стороны, этой теме, возможно, пора переходить в общалку.
Хм. Про технологию RISC и CISC знаю по журналу "Радио" начала 90-ых. 68000 или Sparc - RISC, Z80 или i8086 - CISC.
Сейчас очень популярны "интуитивно понятные интерфейсы". Практически все процессоры имеют хаотическую систему команд. Я на изусть знаю все коды i8080 и i8086. Немного 6802...
На досуге я работаю над вопросом: Можно ли систему команд сделать тоже интуитивно понятной?
Например:
07 - Jmp $+7
25 - load 2 bytes from vector 5
A1 - load Arg[1]
FE - Jmp $-2
Зазубривать такой код почти не надо. Есть эмулятор, написанный на Си под Windows.
Но, я всё же не доволен тем, что код всё ещё был низким и ограниченным. Поэтому я стал идти по другому пути и убрал все коды. Описанный выше имеет всего три операции:
00..7F: NOP
80..BF: LD # ; Загрузка аргументов во фрейм. От 8 до 32 битов
C0..FF: LC # ; Дешифрация команды - от 3 до 10 символов, от 18 до 50 битов
А три операции - считай, что их нет. Это - минимум. Потому я справедливо говорю, что у данной идеи нет системы команд. Теоритически, если сделать это устройство на ПЛМ, то оно будет читать код программы и выдавать на шину лишь код команды (50бит) и размер текущего фрейма. На этом оно и заканчивается. А все операции уже выполняются внешними схемами.
Скажем, подключим к этому устройству схему с двумя моторами и логическое устройство из трёх команд:
Left - включаем левый мотор; Сжатое имя команды - 0x4046A71
Right - включаем правый мотор; Сжатое имя команды - 0x263356C71
STOP - отключаем оба мотора. Сжатое имя команды - 0x56C1328
Тогда можем уже написать программу и вот как выглядит в готовом виде процессора:
Хм. В принципе, схоже с языками ЛОГО и ФОРТ. Но, никакого байт-кода. Прямые шифрованные символьные команды.
Что ж. Прошу прощения, но наверно я просто ошибся разделом или форумом. ;)
Сейчас очень популярны "интуитивно понятные интерфейсы". Практически все процессоры имеют хаотическую систему команд. Я на изусть знаю все коды i8080 и i8086. Немного 6802...
На досуге я работаю над вопросом: Можно ли систему команд сделать тоже интуитивно понятной?
Например:
07 - Jmp $+7
25 - load 2 bytes from vector 5
A1 - load Arg[1]
FE - Jmp $-2
Зазубривать такой код почти не надо. Есть эмулятор, написанный на Си под Windows.
Но, я всё же не доволен тем, что код всё ещё был низким и ограниченным. Поэтому я стал идти по другому пути и убрал все коды. Описанный выше имеет всего три операции:
00..7F: NOP
80..BF: LD # ; Загрузка аргументов во фрейм. От 8 до 32 битов
C0..FF: LC # ; Дешифрация команды - от 3 до 10 символов, от 18 до 50 битов
А три операции - считай, что их нет. Это - минимум. Потому я справедливо говорю, что у данной идеи нет системы команд. Теоритически, если сделать это устройство на ПЛМ, то оно будет читать код программы и выдавать на шину лишь код команды (50бит) и размер текущего фрейма. На этом оно и заканчивается. А все операции уже выполняются внешними схемами.
Скажем, подключим к этому устройству схему с двумя моторами и логическое устройство из трёх команд:
Left - включаем левый мотор; Сжатое имя команды - 0x4046A71
Right - включаем правый мотор; Сжатое имя команды - 0x263356C71
STOP - отключаем оба мотора. Сжатое имя команды - 0x56C1328
Тогда можем уже написать программу и вот как выглядит в готовом виде процессора:
Код:
DF ; Define Frame
08 B8 ; 8
71 6A 04 D4 ; Left
DF ; Define Frame
17 B8 ; 23
71 6C 35 63 DA ; Right
DF ; Define Frame
28 13 6C D5 ; Stop
FF ; Halt
; На нормальном языке это: Left(8); Right(23); Stop(); Halt.
; Включить левый двигатель на 8 тактов, правый - 23 такта, стоп, конец программы.
08 B8 ; 8
71 6A 04 D4 ; Left
DF ; Define Frame
17 B8 ; 23
71 6C 35 63 DA ; Right
DF ; Define Frame
28 13 6C D5 ; Stop
FF ; Halt
; На нормальном языке это: Left(8); Right(23); Stop(); Halt.
; Включить левый двигатель на 8 тактов, правый - 23 такта, стоп, конец программы.
Что ж. Прошу прощения, но наверно я просто ошибся разделом или форумом. ;)
Цитата: Vertecs
Теоритически, если сделать это устройство на ПЛМ, то оно будет читать код программы и выдавать на шину лишь код команды (50бит) и размер текущего фрейма. На этом оно и заканчивается. А все операции уже выполняются внешними схемами.
То есть для каждой программы должна быть запрограммирована своя ПЛМ? Ну или, например, для каждого диалекта вашего языка должна быть своя прошивка ПЛМ? Иначе кто же расшифровывает для "внешних схем" что надо делать?
То есть жертвуем универсальностью и стоимостью аппаратного обеспечения для интуитивности?
Цитата: qwone
А делать процессороподобный язык для людей и человекоподобный язык для процессоров не есть хорошо .
Прекрасная формулировка и мне кажется, автору темы следовало бы попытаться ее как следует осмыслить.
Есть текстовое представление, ориентированное на восприятие человеком, но вполне успешно обрабатываемое копьютером, и бинарное представление, с которым намного удобнее работать компьютеру (если говорить о производительности - это на порядки (не на один!) быстрее), но которое не воспринимается человеком.
У каждого из этих представлений есть свои специфические черты и свои законы преобразования и передачи информации. И попытка унификации здесь ничем хорошим закончится не могут, т.к. в основу положены совершенно различные принципы.
Более того, со временем пропасть между этими двумя представлениями растет (программно это выражается в том, что различие в скорости обработки текстовых и бинарных данных увеличивается, а аппаратно - в том, что все современные процессорные ядра либо работают с кодом, намного менее понятным человеку, чем система команд х86, напрямую, либо преобразуют входной х86-код внутри себя).
Да ладно уж. Процессоры будущего - слишком сильное название темы. :)
Разумнее было бы назвать "Альтернативные микроконтроллеры" или типо того. Люди бы по другому постились ;) надеюсь...
А так, тема уже мусор. Что бы я ни писал))))))))
Разумнее было бы назвать "Альтернативные микроконтроллеры" или типо того. Люди бы по другому постились ;) надеюсь...
А так, тема уже мусор. Что бы я ни писал))))))))
Цитата: Vertecs
Разумнее было бы назвать "Альтернативные микроконтроллеры" или типо того. Люди бы по другому постились ;) надеюсь...
Да. Мысль изложить получилось плохо.
Думаю, что назвать можно было "Оригинальные системы управления".
По идее, можно собрать модель такого устройства. Нужна перепрограммируемая ПЗУ, две ПЛИС(программируемая логическая интегральная схема) и набор светодиодов (ну или мотор).
В ПЗУ будет ваша программа из строк. Одна ПЛИС должна циклически считывать информацию из ПЗУ и преобразовывать его в параллельный код. Вторая будет этот код переваривать и подавать сигнал на определенной командой вывод. Соответственно, будет загараться какой-нибудь светодиод или мотор будет вертеться в нужную сторону.
При том, не важно какие слова будут в программе - первая ПЛИС всегда будет прошита одинаково. Однако, вторая будет прошиваться каждый раз, как потребуется внести изменения в набор слов. И чем больше слов будет, тем сложнее будет реализовать логику.
А как вы в машином коде решите проблему область действия переменных или прогpаммирование без Go to (Jmp) . Ведь все развитие языков программирования было отойти от машинного языка.
Даже язык Си - язык низкого уровня так или иначе "вырос".
Даже язык Си - язык низкого уровня так или иначе "вырос".
Цитата: qwone
А как вы в машином коде решите проблему область действия переменных или прогpаммирование без Go to (Jmp) . Ведь все развитие языков программирования было отойти от машинного языка.
Даже язык Си - язык низкого уровня так или иначе "вырос".
Даже язык Си - язык низкого уровня так или иначе "вырос".
Думаю, автор имел ввиду абстрактное описание, некий язык чисто логического уровня, которым будет описана проблема (программа, цель...). Затем "компилятором" будет воссоздана схема для решения или выполнения. Получается как бы самостроящийся процессор, который оптимально приспособлен под задачу. При этом в нем может не быть никаких предопределенных машинных команд или их структура будет зависеть от логики работы его схемы.
Верно. Абстракция. Но, есть и несколько операций низкого уровня...
Можно описать как:
т.е. вызов процедуры. В устройстве я поступил именно так. Всё равно, что если бы в i80x86 процессоре цикл:
можно было бы описать как:
что нету в процессорах Intel, но логика ясна.
В своей разработке я так и поступил...
Область действия переменных? Хм... Если Вы заметили, есть команда 0xDF - Define Frame. Она открывает скобку "(" - создаёт новый фрейм, который после вызова команды (Left, Right или STOP) передаст только те данные, которые занесены во фрейм. А по возвату из функции (HALT) или аппаратного завершения операции, все данные фрейма приклепляются к фрейму вызывающей функции... Т.е. вот пример на JS:
Т.е. всё просто! И уровень выше, чем Си...
Я ещё думал об использовании Ассоциативных ЗУ(АЗУ), но такой вариант оказался довольно путанным.
Цитата: qwone
А как вы в машином коде решите проблему область действия переменных или прогpаммирование без Go to (Jmp) . Ведь все развитие языков программирования было отойти от машинного языка.
Даже язык Си - язык низкого уровня так или иначе "вырос".
Даже язык Си - язык низкого уровня так или иначе "вырос".
Несколько радует Ваш интерес к моим подходам решения таких задач. Пусть даже "праздный"...
Как я уже сказал, команда может иметь от 3 до 10 символов. Из них, 52 буквы латинского алфавита (строчных и заглавных), 10 цифр, подчёркивание и @т. Итого - 64, т.е. 6 бит на символ. Или из 26 заглавных букв, цифр 1-2-4-8 и тех же знаков. Всего - 32, т.е. 5 бит на символ.
Итого, в расширенных командах - от 3 до 7 символов;
а в командах с заглавными буквами - от 5 до 10.
Идём дальше. Что делать, если пользователь в имени команды поставил не букву, а цифру? Ошибка? Нет. Если цифра "0", то все остальные биты - адрес метки или процедуры для перехода (JMP/CALL). Если цифра "1", читается 1 байт по адресу (CHAR). Если "2", "4" - то ясное дело...
Если цифра "3", то FLOAT (3 байта мантисы + байт экспоненты). То же самое с DOUBLE и т.д... Цифра имеет "интуитивно" ясное и логическое значение.
Составные операции { ...; ...; } или цикл - главная часть "проекта". Я её решил достаточно просто. Например:
Код:
for(i = 0; i < j; i ++) {
if(k < 0) continue;
if(k == 0) break;
...
}
if(k < 0) continue;
if(k == 0) break;
...
}
Код:
BOOL My_Function(int i) {
if(k < 0) return TRUE; // work as continue;
if(k == 0) return FALSE; // work as break;
...
return TRUE;
}
...
for(i = 0; My_Function(i) & (i < j); i ++);
if(k < 0) return TRUE; // work as continue;
if(k == 0) return FALSE; // work as break;
...
return TRUE;
}
...
for(i = 0; My_Function(i) & (i < j); i ++);
Код:
mov ecx,25
L1:
cmp dword ptr [ebx + ecx * 4], 0
js L1
jz L2
...
loop L1
L2:
L1:
cmp dword ptr [ebx + ecx * 4], 0
js L1
jz L2
...
loop L1
L2:
Код:
mov ecx,25
repne call L01
...
L01:
cmp dword ptr [ebx + ecx * 4], 0
js L02
jz L02
...
test ecx, 0
ret
repne call L01
...
L01:
cmp dword ptr [ebx + ecx * 4], 0
js L02
jz L02
...
test ecx, 0
ret
В своей разработке я так и поступил...
Область действия переменных? Хм... Если Вы заметили, есть команда 0xDF - Define Frame. Она открывает скобку "(" - создаёт новый фрейм, который после вызова команды (Left, Right или STOP) передаст только те данные, которые занесены во фрейм. А по возвату из функции (HALT) или аппаратного завершения операции, все данные фрейма приклепляются к фрейму вызывающей функции... Т.е. вот пример на JS:
Код:
function Left(Args) {
x = Args.pop(); y = Args.pop(); ...
Args.push(z);
return Args;
}
...
function Main(Args) {
...
Args = Args.concat(Left(new Array(1, 2, 3)));
...
}
x = Args.pop(); y = Args.pop(); ...
Args.push(z);
return Args;
}
...
function Main(Args) {
...
Args = Args.concat(Left(new Array(1, 2, 3)));
...
}
Я ещё думал об использовании Ассоциативных ЗУ(АЗУ), но такой вариант оказался довольно путанным.
Цитата: Vertecs
1) Нет машинного кода; Программа представляется сжатыми строчками, которые при открытии в редакторе преобразуются в читабильный, символьный вид (add, mov); Все операции читаются и выполняются за такт и быстрее;
Выполняются чем, если это все-таки операции, т.е. коды комплекса действий (неважно, как они представлены)?
Цитата: Vertecs
2) Код может быть как простым, так и сорсным; Сорсный код имеет комментарии и названия к меткам/переменным; Отчистив от них, получаем уже не опенсорс;
Это "технология" будущих процессоров? Парсинг с целью выуживания инструкций-команд среди комментариев?
Цитата: Vertecs
3) Вместо машинного кода - теги, указывающие, что данные нужно обрабатывать как шестнадцатиричное, десятичное, имя метки или как инструкцию; Тем самым в редакторе всё отображается соответствующе;
Опять же - указывающие чему? И для чего, если в конечном итоге все равно данные соответствуют нужным для них командам обработки?
Цитата: Vertecs
Это - поверхностный набросок...
Да уж. Более чем.
Цитата: Vertecs
Имеется JS-версия декодера, преобразующего код в текст. Область применения пока не найдена. Вот фрагмент кода:
16 байтов описывают операции высокого уровня.
Код разрабатывался так, чтобы достичь две цели: Как можно более высокий уровень (не ассемблер с машинным кодом) с формулами; И максимальную простоту, чтобы относительно легко построить на ПЛИС.
Код:
DF DF ; ( (
79 28 C1 ; (double)dx
6F 66 C2 ; )abs
13 10 C1 ; (long)Le
16 52 09 D4 FF ; )LONG;
; equal -> long Le = (long)abs((double)dx);
79 28 C1 ; (double)dx
6F 66 C2 ; )abs
13 10 C1 ; (long)Le
16 52 09 D4 FF ; )LONG;
; equal -> long Le = (long)abs((double)dx);
Код разрабатывался так, чтобы достичь две цели: Как можно более высокий уровень (не ассемблер с машинным кодом) с формулами; И максимальную простоту, чтобы относительно легко построить на ПЛИС.
Про реализацию кода ничего не скажу, хотя особого "высокого уровня" я тут что-то не замечаю. Использование abs и приведений, IMHO, еще не высокий уровень. Ассемблер - транслятор мнемонических описаний машинных команд или их комплексных представлений.
В общем, складывается впечатление, что этот "процессор" - не более, чем парсер определенных лексем, к каждой из которых привязано некое контролируемое действие, "аппаратный" блок, который вызывается и связанные с ним данные обрабатывает своими внутренними способами, выдавая результат в определенной (общей?) форме.
Цитата: REmindER
Выполняются чем, если это все-таки операции, т.е. коды комплекса действий (неважно, как они представлены)?
Внешними устройствами. Пусть хоть даже Z80 с ПЗУ и уймой страниц; Можно и i80387...
Цитата: REmindER
Это "технология" будущих процессоров? Парсинг с целью выуживания инструкций-команд среди комментариев?
Опен-сорс скачиваем, в редакторе опцией убераем всё читабильное и сохраняем в нужный файл.
Цитата: REmindER
Опять же - указывающие чему? И для чего, если в конечном итоге все равно данные соответствуют нужным для них командам обработки?
Всему, что хотите. Хоть светодиодам, хоть холодильнику.
Цитата: REmindER
Да уж. Более чем.
По Вашему я должен открыть всё? Поверхностный набросок для форума я имел в виду;)
Цитата: REmindER
Про реализацию кода ничего не скажу, хотя особого "высокого уровня" я тут что-то не замечаю. Использование abs и приведений, IMHO, еще не высокий уровень. Ассемблер - транслятор мнемонических описаний машинных команд или их комплексных представлений.
Понимаю. Я команды представил как попало. Опять таки, для форума...
Цитата: REmindER
В общем, складывается впечатление, что этот "процессор" - не более, чем парсер определенных лексем, к каждой из которых привязано некое контролируемое действие, "аппаратный" блок, который вызывается и связанные с ним данные обрабатывает своими внутренними способами, выдавая результат в определенной (общей?) форме.
Да. Именно! Парсер! Первый мой парсер переводил
Код:
ah=09h;dx=0msgHello#021h=04Ch#021h
Код:
mov ah,09h
mov dx,offset msgHello
int 021h
mov ah,04Ch
int 021h
mov dx,offset msgHello
int 021h
mov ah,04Ch
int 021h
Вот, решил от ассемблера перейти к матрицам ;)
Цитата: Vertecs
Хм. Про технологию RISC и CISC знаю по журналу "Радио" начала 90-ых. 68000 или Sparc - RISC, Z80 или i8086 - CISC.
Сейчас очень популярны "интуитивно понятные интерфейсы". Практически все процессоры имеют хаотическую систему команд. Я на изусть знаю все коды i8080 и i8086. Немного 6802...
На досуге я работаю над вопросом: Можно ли систему команд сделать тоже интуитивно понятной?
Например:
07 - Jmp $+7
25 - load 2 bytes from vector 5
A1 - load Arg[1]
FE - Jmp $-2
Зазубривать такой код почти не надо. Есть эмулятор, написанный на Си под Windows.
Но, я всё же не доволен тем, что код всё ещё был низким и ограниченным. Поэтому я стал идти по другому пути и убрал все коды. Описанный выше имеет всего три операции:
00..7F: NOP
80..BF: LD # ; Загрузка аргументов во фрейм. От 8 до 32 битов
C0..FF: LC # ; Дешифрация команды - от 3 до 10 символов, от 18 до 50 битов
А три операции - считай, что их нет. Это - минимум. Потому я справедливо говорю, что у данной идеи нет системы команд. Теоритически, если сделать это устройство на ПЛМ, то оно будет читать код программы и выдавать на шину лишь код команды (50бит) и размер текущего фрейма. На этом оно и заканчивается. А все операции уже выполняются внешними схемами.
Скажем, подключим к этому устройству схему с двумя моторами и логическое устройство из трёх команд:
Left - включаем левый мотор; Сжатое имя команды - 0x4046A71
Right - включаем правый мотор; Сжатое имя команды - 0x263356C71
STOP - отключаем оба мотора. Сжатое имя команды - 0x56C1328
Тогда можем уже написать программу и вот как выглядит в готовом виде процессора:
Хм. В принципе, схоже с языками ЛОГО и ФОРТ. Но, никакого байт-кода. Прямые шифрованные символьные команды.
Что ж. Прошу прощения, но наверно я просто ошибся разделом или форумом. ;)
Сейчас очень популярны "интуитивно понятные интерфейсы". Практически все процессоры имеют хаотическую систему команд. Я на изусть знаю все коды i8080 и i8086. Немного 6802...
На досуге я работаю над вопросом: Можно ли систему команд сделать тоже интуитивно понятной?
Например:
07 - Jmp $+7
25 - load 2 bytes from vector 5
A1 - load Arg[1]
FE - Jmp $-2
Зазубривать такой код почти не надо. Есть эмулятор, написанный на Си под Windows.
Но, я всё же не доволен тем, что код всё ещё был низким и ограниченным. Поэтому я стал идти по другому пути и убрал все коды. Описанный выше имеет всего три операции:
00..7F: NOP
80..BF: LD # ; Загрузка аргументов во фрейм. От 8 до 32 битов
C0..FF: LC # ; Дешифрация команды - от 3 до 10 символов, от 18 до 50 битов
А три операции - считай, что их нет. Это - минимум. Потому я справедливо говорю, что у данной идеи нет системы команд. Теоритически, если сделать это устройство на ПЛМ, то оно будет читать код программы и выдавать на шину лишь код команды (50бит) и размер текущего фрейма. На этом оно и заканчивается. А все операции уже выполняются внешними схемами.
Скажем, подключим к этому устройству схему с двумя моторами и логическое устройство из трёх команд:
Left - включаем левый мотор; Сжатое имя команды - 0x4046A71
Right - включаем правый мотор; Сжатое имя команды - 0x263356C71
STOP - отключаем оба мотора. Сжатое имя команды - 0x56C1328
Тогда можем уже написать программу и вот как выглядит в готовом виде процессора:
Код:
DF ; Define Frame
08 B8 ; 8
71 6A 04 D4 ; Left
DF ; Define Frame
17 B8 ; 23
71 6C 35 63 DA ; Right
DF ; Define Frame
28 13 6C D5 ; Stop
FF ; Halt
; На нормальном языке это: Left(8); Right(23); Stop(); Halt.
; Включить левый двигатель на 8 тактов, правый - 23 такта, стоп, конец программы.
08 B8 ; 8
71 6A 04 D4 ; Left
DF ; Define Frame
17 B8 ; 23
71 6C 35 63 DA ; Right
DF ; Define Frame
28 13 6C D5 ; Stop
FF ; Halt
; На нормальном языке это: Left(8); Right(23); Stop(); Halt.
; Включить левый двигатель на 8 тактов, правый - 23 такта, стоп, конец программы.
Что ж. Прошу прощения, но наверно я просто ошибся разделом или форумом. ;)
Да фиг с ней - с "интуитивностью" системы команд. Кто полезет в такие дебри? И почему это "никакого байт-кода"? А что считать байт-кодом? Имя функции? Код операции? Номер соответствующей подпрограммы, ее реализующей? Если по отношению к дешифратору она является внешней (внешней схемой)? Так не все ли равно как ее вызывать: кодом, словом или сигналом? И наличие понятия обработки ею как-либо данных уже подразумевает существование промежуточного интерфейса. Так что в данном случае код все равно есть. Не напоминает принцип обращения к переферии через порты? В этом случае номер порта - код операции или подключение работы внешней схемы.
Цитата: REmindER
Да фиг с ней - с "интуитивностью" системы команд. Кто полезет в такие дебри? И почему это "никакого байт-кода"? А что считать байт-кодом? Имя функции? Код операции? Номер соответствующей подпрограммы, ее реализующей? Если по отношению к дешифратору она является внешней (внешней схемой)? Так не все ли равно как ее вызывать: кодом, словом или сигналом? И наличие понятия обработки ею как-либо данных уже подразумевает существование промежуточного интерфейса. Так что в данном случае код все равно есть. Не напоминает принцип обращения к переферии через порты? В этом случае номер порта - код операции или подключение работы внешней схемы.
Хм. Да. Был у меня вариант "настоящего" RISC-процессора с мощной системой команд. Система состояла из 8 страниц команд по 224 кода в каждой. Остальные 32 команды были статическими. Были страницы: Работы с данными; Вызова и перехода; Арифметики; BIOS; Пользовательских библиотек; Аппаратуры (вместо портов); И ПЛМ, где каждый из 224 кодов означает свою прошивку ПЛИС заданной в приложении индивидуально... Года 3, а то и 7 лет возился. Но эмулятор так и не написал. Лишь наброски остались в тексте и таблиц команд.
Теперь вот увлёкся этим контроллером...
Цитата: Vertecs
Вот, решил от ассемблера перейти к матрицам ;)
А для чего это все? Если концептуально это ничего нового не несет? Если способ обращения к схеме-команде уже подразумевает зависимость от ее реализации, значит, обобщение существует только на уровне "дешифратора"? Что тут особо нового, кроме обращений к узлам по именам, а не по номерам? Этот "дешифратор", получается, ВМ, только как автономное устройство с командами в виде схем периферии.
Vertecs, что мы пытаемся описать? Язык программирования или процессор? Это существенно различные и в общем случае никак не связанные субстанции.
Для того, чтобы их связать, существуют компиляторы, кстати, величайшее изобретение в истории программирования.
Набор требований, предъявляемых к языкам программирования и процессорам совершенно различен.
Кстати, обратите внимание, что в окружающем нас мире прекрасно уживаются как различные процессоры, так и различные языки програмирования, что говорит о том, что "лучшего" среди них нет - у каждого есть преимущества при использовании в той или иной области. Другими словами, в зависимости от стоящей перед нами задачи мы выбираем наиболее подходящий для ее решения язык программирования. И, кстати, точно так же (только, исходя из других критериев) поступаем с процессором.
Так что попятка отменить ЯВУ и вернуться к программированию в машинных кодах - есть безусловный регресс.
Для того, чтобы их связать, существуют компиляторы, кстати, величайшее изобретение в истории программирования.
Набор требований, предъявляемых к языкам программирования и процессорам совершенно различен.
Кстати, обратите внимание, что в окружающем нас мире прекрасно уживаются как различные процессоры, так и различные языки програмирования, что говорит о том, что "лучшего" среди них нет - у каждого есть преимущества при использовании в той или иной области. Другими словами, в зависимости от стоящей перед нами задачи мы выбираем наиболее подходящий для ее решения язык программирования. И, кстати, точно так же (только, исходя из других критериев) поступаем с процессором.
Так что попятка отменить ЯВУ и вернуться к программированию в машинных кодах - есть безусловный регресс.
Цитата: andriano
Vertecs, что мы пытаемся описать? Язык программирования или процессор? Это существенно различные и в общем случае никак не связанные субстанции.
Для того, чтобы их связать, существуют компиляторы, кстати, величайшее изобретение в истории программирования.
Набор требований, предъявляемых к языкам программирования и процессорам совершенно различен.
Кстати, обратите внимание, что в окружающем нас мире прекрасно уживаются как различные процессоры, так и различные языки програмирования, что говорит о том, что "лучшего" среди них нет - у каждого есть преимущества при использовании в той или иной области. Другими словами, в зависимости от стоящей перед нами задачи мы выбираем наиболее подходящий для ее решения язык программирования. И, кстати, точно так же (только, исходя из других критериев) поступаем с процессором.
Так что попятка отменить ЯВУ и вернуться к программированию в машинных кодах - есть безусловный регресс.
Для того, чтобы их связать, существуют компиляторы, кстати, величайшее изобретение в истории программирования.
Набор требований, предъявляемых к языкам программирования и процессорам совершенно различен.
Кстати, обратите внимание, что в окружающем нас мире прекрасно уживаются как различные процессоры, так и различные языки програмирования, что говорит о том, что "лучшего" среди них нет - у каждого есть преимущества при использовании в той или иной области. Другими словами, в зависимости от стоящей перед нами задачи мы выбираем наиболее подходящий для ее решения язык программирования. И, кстати, точно так же (только, исходя из других критериев) поступаем с процессором.
Так что попятка отменить ЯВУ и вернуться к программированию в машинных кодах - есть безусловный регресс.
Он как раз таки пытается отменить машинные коды, как я понимаю. Каким образом только, не пойму.
Цитата: andriano
Vertecs, что мы пытаемся описать? Язык программирования или процессор? Это существенно различные и в общем случае никак не связанные субстанции.
Для того, чтобы их связать, существуют компиляторы, кстати, величайшее изобретение в истории программирования.
Набор требований, предъявляемых к языкам программирования и процессорам совершенно различен.
Кстати, обратите внимание, что в окружающем нас мире прекрасно уживаются как различные процессоры, так и различные языки програмирования, что говорит о том, что "лучшего" среди них нет - у каждого есть преимущества при использовании в той или иной области. Другими словами, в зависимости от стоящей перед нами задачи мы выбираем наиболее подходящий для ее решения язык программирования. И, кстати, точно так же (только, исходя из других критериев) поступаем с процессором.
Так что попятка отменить ЯВУ и вернуться к программированию в машинных кодах - есть безусловный регресс.
Для того, чтобы их связать, существуют компиляторы, кстати, величайшее изобретение в истории программирования.
Набор требований, предъявляемых к языкам программирования и процессорам совершенно различен.
Кстати, обратите внимание, что в окружающем нас мире прекрасно уживаются как различные процессоры, так и различные языки програмирования, что говорит о том, что "лучшего" среди них нет - у каждого есть преимущества при использовании в той или иной области. Другими словами, в зависимости от стоящей перед нами задачи мы выбираем наиболее подходящий для ее решения язык программирования. И, кстати, точно так же (только, исходя из других критериев) поступаем с процессором.
Так что попятка отменить ЯВУ и вернуться к программированию в машинных кодах - есть безусловный регресс.
Ну... Попытка - не пытка, если она доставляет удовольствие...
Во-первых, ко многим идеям исторически относились критически. Вспомните знаменитый "Тетрис" или велосипед... Я не говорю, что я делаю нечто революционное. Просто, это - форум. И все детали задумки открывать, естественно, опасно.
"Бойся молчиливых" - руководствуюсь этим. Вот Вы все критикуете (в хорошем смысле слова), а другие - просто наблюдают и высматривать могут ключевые моменты идеи.
Я не отменяю ЯВУ, а пытаюсь дотануть низкий уровень до него. Первый вариант такого "процессора" (Версия №1) был таким:
Код:
0x20 : Push(d)
...
0x30 0 : if(m == 0) { m = 8; d = 0; } else { d = d * m; }
0x31 1 : if(m == 0) { m = 10; d = 1; } else { d = d * m + (0x31 & 15); }
...
0x41 A : if(m == 0) { m = 32; d = 1; } else { d = d * m + (0x41 & 31); }
...
...
0x30 0 : if(m == 0) { m = 8; d = 0; } else { d = d * m; }
0x31 1 : if(m == 0) { m = 10; d = 1; } else { d = d * m + (0x31 & 15); }
...
0x41 A : if(m == 0) { m = 32; d = 1; } else { d = d * m + (0x41 & 31); }
...
Теперь я несколько изменил принцип. Сначала идут данные (0-127 - Nop), которые устройство игнорирует, а затем операции чтения слова нужной длины из проигнорированных ячеек. Программная модель сразу стала легче, да и аппаратно, думаю, в OrCAD смогу воспроизвести...
Логика устройства упростилась чрезвычайно, по сравнению с первым вариантом. Никаких ПЗУ и дешифраторов. Просто набор элементов "И", три счётчика и регистры. Просто удовольствие работать над нечто простым. :)
Жалко, OrCAD не эмулирует ПЗУ/ОЗУ, а то было бы вообще... Или я не разобрался?
Кстати. http://www.forth.org.ru/~drom/forthcpu/misc.html
Эта статья была огромным стимулом. Когда я возился с версией №1, я наткнулся на статью и заметил нечто общее: Я отталкивался от Форт-модели тоже. А статья простимулировала поиск простейщего. Ну, стал искать способы, достичь простой схемой высокого(!) уровня...
Как говорят Богословы, что даже клеточка или атом могут молиться и общаться с Творцом. Так почему же не попытаться ни кодеров опускать до понимания низкого машинного кода, а сам уровень поднять до "человеческого".
Иными словами: Кодер - Творец. Машина - набор клеток. По моему лучше набор клеток научить "молиться" на привычном для кодера языке, чем топить его в мире примитивного клеточного лепета... :)
Цитата: Vertecs
Ну... Попытка - не пытка, если она доставляет удовольствие...
Во-первых, ко многим идеям исторически относились критически. Вспомните знаменитый "Тетрис" или велосипед... Я не говорю, что я делаю нечто революционное. Просто, это - форум. И все детали задумки открывать, естественно, опасно.
"Бойся молчиливых" - руководствуюсь этим. Вот Вы все критикуете (в хорошем смысле слова), а другие - просто наблюдают и высматривать могут ключевые моменты идеи.
Я не отменяю ЯВУ, а пытаюсь дотануть низкий уровень до него. Первый вариант такого "процессора" был таким:
т.е. все команды были читабильные и программа была обычным текстом. Однако, на ввод одного числа уходило много тактов, а на имя команды - ещё больше. Думал решить проблему разовым чтением 32 байтов сразу, а потом бандой 32 ПЗУ-дешифраторов находить длину записи. Но, тогда требовалась очень сложная логика в соглосовании пачки ПЗУ, да и прошивку никак не удалось разработать. Плюс память требовалась до 256 разрядов.
Теперь я несколько изменил принцип. Сначала идут данные (0-127 - Nop), которые устройство игнорирует, а затем операции чтения слова нужной длины из проигнорированных ячеек. Программная модель сразу стала легче, да и аппаратно, думаю, в OrCAD смогу воспроизвести...
Логика устройства упростилась чрезвычайно, по сравнению с первым вариантом. Никаких ПЗУ и дешифраторов. Просто набор элементов "И", три счётчика и регистры. Просто удовольствие работать над нечто простым. :)
Жалко, OrCAD не эмулирует ПЗУ/ОЗУ, а то было бы вообще... Или я не разобрался?
Во-первых, ко многим идеям исторически относились критически. Вспомните знаменитый "Тетрис" или велосипед... Я не говорю, что я делаю нечто революционное. Просто, это - форум. И все детали задумки открывать, естественно, опасно.
"Бойся молчиливых" - руководствуюсь этим. Вот Вы все критикуете (в хорошем смысле слова), а другие - просто наблюдают и высматривать могут ключевые моменты идеи.
Я не отменяю ЯВУ, а пытаюсь дотануть низкий уровень до него. Первый вариант такого "процессора" был таким:
Код:
0x20 : Push(d)
...
0x30 0 : if(m == 0) { m = 8; d = 0; } else { d = d * m; }
0x31 1 : if(m == 0) { m = 10; d = 1; } else { d = d * m + (0x31 & 15); }
...
0x41 A : if(m == 0) { m = 32; d = 1; } else { d = d * m + (0x41 & 31); }
...
...
0x30 0 : if(m == 0) { m = 8; d = 0; } else { d = d * m; }
0x31 1 : if(m == 0) { m = 10; d = 1; } else { d = d * m + (0x31 & 15); }
...
0x41 A : if(m == 0) { m = 32; d = 1; } else { d = d * m + (0x41 & 31); }
...
Теперь я несколько изменил принцип. Сначала идут данные (0-127 - Nop), которые устройство игнорирует, а затем операции чтения слова нужной длины из проигнорированных ячеек. Программная модель сразу стала легче, да и аппаратно, думаю, в OrCAD смогу воспроизвести...
Логика устройства упростилась чрезвычайно, по сравнению с первым вариантом. Никаких ПЗУ и дешифраторов. Просто набор элементов "И", три счётчика и регистры. Просто удовольствие работать над нечто простым. :)
Жалко, OrCAD не эмулирует ПЗУ/ОЗУ, а то было бы вообще... Или я не разобрался?
Да никто тебя особо не критикует, а просто пытаются понять итог того, что должно получиться. Ты говоришь большей частью какими-то деталями. Если боишься, что кто-то украдет идею, зачем тогда разговор заводишь? В общем, если я правильно понимаю идею, то скажу, что ничего особенно нового я в ней не вижу. Получается некий обособленный вариант уже существующих на данный момент систем.
Цитата: REmindER
Да никто тебя особо не критикует, а просто пытаются понять итог того, что должно получиться. Ты говоришь большей частью какими-то деталями. Если боишься, что кто-то украдет идею, зачем тогда разговор заводишь? В общем, если я правильно понимаю идею, то скажу, что ничего особенно нового я в ней не вижу. Получается некий обособленный вариант уже существующих на данный момент систем.
Ну, да. Говорю же, minimal Forth-CPU была огромным стимулом. Тот процессор можно назвать "игрушечным". Ну, а я что? Записался в НАСА чтобы ракеты строить? Лучше буду возиться с игрушками, так интереснее:)
Цитата: Vertecs
Ну, да. Говорю же, minimal Forth-CPU была огромным стимулом. Тот процессор можно назвать "игрушечным". Ну, а я что? Записался в НАСА чтобы ракеты строить? Лучше буду возиться с игрушками, так интереснее:)
А, просто, значит, выговориться захотелось? Так бы сразу и сказал, и мы бы тоже потрепались всилу своего желания и обстоятельств, если тебе так легче. Ну что ж, удачи тогда. :)
Цитата: REmindER
А, просто, значит, выговориться захотелось? Так бы сразу и сказал, и мы бы тоже потрепались всилу своего желания и обстоятельств, если тебе так легче. Ну что ж, удачи тогда. :)
Удачи? Выходит, тема изчерпала себя...
Да, много ошибок допустил. Начиная таким вопиющим названием темы. Аж стыдно сейчас...
Впредь буду поскромнее с заголовками... ;)
А по поводу "удачи". Как я уже спрашивал: Имеются ли сайты коллективов, занимающихся подобным? А то всякие УФОлогические есть море. А мне что делать? эм-ммм...
Цитата: Vertecs
Ну, да. Говорю же, minimal Forth-CPU была огромным стимулом. Тот процессор можно назвать "игрушечным". Ну, а я что? Записался в НАСА чтобы ракеты строить? Лучше буду возиться с игрушками, так интереснее:)
Ка-бы все было так просто... Не создавал бы Интел Коров2 и Пентиумов, не было бы векторных вычислителей на базе GPU, не нужно было бы создавать гибридные суперЭВМ, в которых критические участки алгоритмов реализуются на ПЛИС....
Цитата: Vertecs
А по поводу "удачи". Как я уже спрашивал: Имеются ли сайты коллективов, занимающихся подобным? А то всякие УФОлогические есть море. А мне что делать? эм-ммм...
Разработкой контроллеров на основе ПЛИС? Обычно занимаются конкретными вещами, таких сайтов море. Я просто так и не понял, что тебя интересует. Разработка интерфейсов аппаратной части схем-команд? Тут уж как сам решишь, я думаю.
Цитата: Vertecs
Я не отменяю ЯВУ, а пытаюсь дотануть низкий уровень до него.
А это и не нужно.
Есть две разные сущности: алгоритм на ЯВУ и машинный код. И не надо пытаться их скрестить, ничего хорошего из этого не получится.
Цитата:
Первый вариант такого "процессора" (Версия №1) был таким:
Во всех примерах, увы, фигурируют достаточно примитивные конструкции. Я онимаю, что для демонсрационных примеров трудно подобрать что-либо другое.
Но все таки, как в таком низкоуровневым языке можно, не теряя эффективности, обеспечить, скажем, контроль типов (включая пользовательские типы) или инкапсуляцию?
Цитата:
По моему лучше набор клеток научить "молиться" на привычном для кодера языке, чем топить его в мире примитивного клеточного лепета... :)
Это можно сделать различными способами. Человечество уже изобрело эффективный - трансляторы. Вы предлагаете трансляцией заниматься процессору на стадии выполнения. Но этот путь тоже известен - он называется интерпретацией. И также хорошо известны основные недостатки этого метода, в частности, существенное снижение производительности. Вы предлагаете аппаратный интерпретатор, но таковой уже есть в виде всех современных х86-совместимых процессоров, тратящих 3/4 мощности на преобразование высокоуровневого набора инстукций х86 во внутренний RISC код, и только 1/4 - на его исполнение. Вы предлагаете еще больше усугубить это соотношение?
Цитата: hardcase
Ка-бы все было так просто... Не создавал бы Интел Коров2 и Пентиумов, не было бы векторных вычислителей на базе GPU, не нужно было бы создавать гибридные суперЭВМ, в которых критические участки алгоритмов реализуются на ПЛИС....
Ага. Меня страшно интересует вопрос "Почему Intel никак не введут в Pentium PLD и команды для управления ими?".
Скажем, вместо эмулятора процессоров Dendy или Sega не программный код, а уже прошивка встроенной ПЛИС. Как было бы замечтально! Представьте, сложная программа рендеринга 3D сцену просчитывает за сто тактов всего! Благодаря тому, что Pentium имеет ПЛИС с памятью из тысяч страниц. Сначала включается прошивка №1 и схема запускается, тактируется. Затем фиксируется результат и включается прошивка №2, которой передаётся результат-сигналы, сгенерированные предыдущей прошивкой. И так далее. Можно прошивать просто огромные схемы, разбивая их на несколько узлов. А программно уже вызывать ту или иную схему как процедуру. И стройте тогда хоть узлы космического корабля! Правда, чем больше схема, тем больше тактов будет уходить на узел и согласование. Но, по сравнению с чисто программной моделью в производительности это выигрывает в тысячи раз! Теоритически.
А на практике. Я долго пытался к этому подойти. Как говорил выше, у меня была модель процессора со страницей из 224 команд ПЛМ, где команда - просто номер прошивки схемы. Правда, застрял сильно. Не смог решить проблему передачи сигналов из одной схемы в следующую... Не смог на теоритическом плане, не говоря уже о модели эмуляции такого процессора... Не смог я, для которого программирование и электронника - хобби, но не специальность...
А что же делают инженеры Intel? Уж им то это под силу! Но они не станут делать по экономическим и стратегическим соображениям:
Кому нужен Pentium-25, если Pentium-6 можно просто прошить? Не просто прошить, а прошивать на лету в многозадачной ОС, где каждая задача по своему прошила нужные инструкции...
Цитата: Vertecs
Ага. Меня страшно интересует вопрос "Почему Intel никак не введут в Pentium PLD и команды для управления ими?".
Это можно реализовать средставами чипсета. Каждый выполняет свою задачу:
Процессор - универсальный вычислитель.
Плис, стоящая в гнезде PCI-Express - реконфигурируемый вчислитель.
А шина (вернее сеть) PCI-Express позволяет очень эффективно обращаться к оперативной памяти машины. Компьютеры на основе такой схемы уже давно разрабатывается, и у нас и за рубежом (Cray такие кампутеры продает).
Тут проблема в другом. Эффективно запрограммировать ПЛИС - дико сложная задача для рядового прикладника, ибо сейчас нету УДОБНОГО языка для воплощения вычислительных задач в кристалле.
Цитата: andriano
Но все таки, как в таком низкоуровневым языке можно, не теряя эффективности, обеспечить, скажем, контроль типов (включая пользовательские типы) или инкапсуляцию?
Было такое. Каждый регистр имел вспомогательные биты, указывающие на тип данных в регистре. АЛУ само всё делала, конвертируя типы.
Цитата: andriano
Это можно сделать различными способами. Человечество уже изобрело эффективный - трансляторы.
Старая тема. Типо "человек не может с Богом общаться и Бог не может напрямую разговаривать с человеком. Нужны пророки, богословы, церкви". Эту уже сектантство! :D Си - одна церковь, Дельфи - вторая, Асм - сатанизм. :D Посмотрите, люди и компьютерный мир сделали таким же. Одни секты и у каждой свой опиум.
Си и Си++ чем отличаются? Одна и та же секта, но опиум у других крепче... :)
А меня интересует, как говорил уже, непосредственный диалог программист-процессор...
Цитата: Vertecs
Старая тема. Типо "человек не может с Богом общаться и Бог не может напрямую разговаривать с человеком. Нужны пророки, богословы, церкви". Эту уже сектантство! :D Си - одна церковь, Дельфи - вторая, Асм - сатанизм. :D Посмотрите, люди и компьютерный мир сделали таким же. Одни секты и у каждой свой опиум.
Си и Си++ чем отличаются? Одна и та же секта, но опиум у других крепче... :)
А меня интересует, как говорил уже, непосредственный диалог программист-процессор...
Си и Си++ чем отличаются? Одна и та же секта, но опиум у других крепче... :)
А меня интересует, как говорил уже, непосредственный диалог программист-процессор...
В итоге принцип один и тот же. Все оканчивается уровнем общения. С таким же успехом можно написать список действий на бумажке и сидеть выполнять их в уме.
Оффтоп: Заметьте. Си - полумесяц, ++ - два креста. C++ - сектантский союз мусульман и христиан? Два креста - католики и православные.
Если так смотреть, то не только валюта Евро имеет символ Quake, но и ЯВУ - сплошная религия :D
Интересно. Случайно ли это? Чего стоят только в Виндовсе пиктограммы именуемые "Иконами"! :) )))
Если так смотреть, то не только валюта Евро имеет символ Quake, но и ЯВУ - сплошная религия :D
Интересно. Случайно ли это? Чего стоят только в Виндовсе пиктограммы именуемые "Иконами"! :) )))
Действительно - оффтоп.
Цитата: hardcase
Это можно реализовать средставами чипсета. Каждый выполняет свою задачу:
Процессор - универсальный вычислитель.
Плис, стоящая в гнезде PCI-Express - реконфигурируемый вчислитель.
Процессор - универсальный вычислитель.
Плис, стоящая в гнезде PCI-Express - реконфигурируемый вчислитель.
Интересно, а такую готовую карточку с ПЛИС достать реально? Чтобы не возиться с J-Tag'ами всякими...
Если взять радиолюбительские персоналки 80-ых:
Микро-80; Радио-86РК; Микроша; Специалист; Орион-128 и т.д. (процессор-аналог i8080A)
то можно заметить, что практически все трансляторы весили достаточно мало:
Строчный редактор текстов - 2Кб;
Ассемблер (полноценный: метки и т.д.) - 2Кб;
Дизассемблер (полноценный) - 2Кб;
Комплект Редактор+Ассемблер или Редактор+Дизассемблер - 4Кб;
Отладчик - 4Кб;
Интерпретатор языка Бейсик - 8Кб;
и т.д.
При том, что сама BIOS (программа "Монитор" с базовыми 17-ю функциями) весила 2Кб.
Т.е. 2Кб - не случайная цифра, а предельный минимум всех утилит разработчика (не считая Бейсика).
Теперь посмотрите на x86. Ассемблер+Дизассемблер+Отладчик = Debug (неполноценный: ни меток, ни EQU) 20Кб. Если сравнивать с i8080-средствами, то ставится 6Кб относительно "полноценных" средств i8080 против 20Кб дубового Debug-x86. Т.е. по 10 кб на декодер кода и кодер мнемоники. Ассемблером не пахнет.
Это не критика, а простая попетка оценить средний минимум затрачиваемых средств для работы с процессором на уровне ассемблера. Идём дальше...
В мире всё квантуется - говорят физики. А почему? Не знает никто! Квантуется и всё!
А каков минимальный квант любой современный ОС? Ясное дело, это бут-сектор и весит этот квант - 512 байт.
Возможно ли втиснуть какое-нибудь средство разработки в этот квант? Я попробовал... Написал Forth.com средствами HIEW и получился диалоговый Форт размером 512 байтов. При том, что слова DUP/DROP/OVER/SWAP у меня обрабатываются как простые числа, но с битом "не число" по алгоритму, где у буквы просто берётся младшие 4 бита. DROP умещается в 0x42F0 - и т.д... Что там говорить о мнемониках и метках.
Вот, в попытках разработать свой микроконтроллер (или процессор. Называйте как хотите) с "высокоуровневым" (не сравнивать с уровнем ЯВУ или макро-ассемблера. Уровень высокий для контроллеров) представлением кода, то можно говорить, что Вьювер кода (дизассемблер) можно уместить уже в бут-сектор (PC разумеется).
Можно сказать, как сейчас практически "модно": USB-протокол, FTP/HTTP-протоколы, протоколы PATA/SATA/COM/LPT, и т.д.
У x86 свой протокол машинного кода ( :D ), а у моего - свой... Можно сказать, ассемблер - шифровщик протокола, дизассемблер - дешифровщик. Мой контроллер в таком случае выигрывает в двух пунктах:
Протокол высокого, символического уровня;
Протокол предельно прост для шифрования и дешифрования.
Именно это, меня в частности, меня здорово привлекло. Не то, что это Я придумал. А то, что это просто можно достичь...