LLVM компилятор для БК0011М/БК12 - Электроника БК-0010/0011M

ЛАТ

LLVM компилятор для БК0011М/БК12
[+] Старые сообщения (5)
? Дмитрий - 01.04.2014 15:14
Никсы малопригодны для БК, это уже обсуждалось - нет ММУ и фич, присущих современным архитектурам, под которые они заточены. Обрезать можно, исключив то, что не поддерживается. Но в итоге останется клон АНДОС/МКДОС несовместимый ни с чем и немного превосходящий их. А именно этой "фишкой" все и недовольны. Как я уже говорил (и не только я) БК12 пошел в ту же сторону, что и 10/11/М - в сторону своей уникальности и несовместимости. По идее нужно было либо делать полный клон ПДП11, либо разрабатывать новый проц на ПЛИС с системой команд БК (с префиксами или самостоятельную, новую) и с уклоном на современную архитектуру, чтобы портировать имеющийся открытый софт.
? Дмитрий - 01.04.2014 15:18
По поводу DragonEgg: это все отлично, но слишком громоздкая схема получается: GCC->LLVM->код.
? Аноним - 02.04.2014 01:07
Может, все же ваш "разработчик" выложит то, что сделал на github и без всяких "руководств" обойдемся? Еще бы неплохо посмотреть под что вобще его делают. Мы до сих пор не имеем описание архитектуры.
? Voland@ - 02.04.2014 10:01
>> Мы до сих пор не имеем описание архитектуры.
Потому что она четко еще не сформирована. После выпуска Booster начнем вплотную заниматься БК12. Пока надо ориентироваться на компиляцию под ВМ1.
¤
>> без всяких "руководств" обойдемся?
Я так не думаю. Тут у кого-то есть глубокий опыт руководством группой специалистов, разрабатывающих промышленные компиляторы?
Да и дело не только в этом, уже неоднократно замечено, что запал энтузиазма через какое-то время проходит, работа забрасывается на какой-то непонятной стадии, а кто продолжать будет? Придется разработчику ковыряться, разбираться с тем, что кто-то на полпути забросил и переправлять всё "по себя" ?
И неплохо бы сначала объявить о своих планах и намерениях, а не анонимно вбросы какие-то делать. Хотя я конечно понимаю, что для кого-то наличие даже условного "руководства" - это как серпом по яйцам.
? Voland@ - 02.04.2014 10:04
>> Никсы малопригодны для БК, это уже обсуждалось
>> По поводу DragonEgg: это все отлично, но слишком громоздкая схема получается: GCC->LLVM->код.
для основных языков вроде C/C++ всё и без DragonEgg хорошо, а для каких-нибудь маргинальных вроде Фортрана - ничего страшного. Что касаемо всяких там MMU и "несовместимости", то как говаривал небезызвестный автор суперкомпьютеров Seymour Cray - "MMU - for farmers" - на самом деле, задача MMU- это чтобы разные процессы случайно не залезли в память друг друга ну и заодно аппаратная поддержка виртуальной памяти. На любительской системе и то и другое неактуально. Особой проблемы во всяких MMU нет, но это просто дополнительный расход времени и сил на проектирование.
? Дмитрий - 02.04.2014 11:13
>> Что касаемо всяких там MMU и "несовместимости"
Это вы не мне, а нападавшим и неприемлющим новую ДОС объясняйте. Меня устроит даже однозадачная ОС - мы же не сервер Пентагона разрабатываем. Да и многозадачность на БК не нужна.
? Voland@ - 02.04.2014 16:24
Итак, один человек вроде бы уже есть: http://zx.pk.ru/showpost.php?p=696717&postcount=6
¤
Причем это не просто человек, а с опытом портирования LLVM на спектруме, там есть ссылка на ветку, где он вел свою работу.
Но, как он заметил, надо еще 1-2 людей, иначе он не согласен.
? anonymous - 02.04.2014 20:14
「на самом деле, задача MMU- это чтобы разные процессы случайно не залезли в память друг друга ну и заодно аппаратная поддержка виртуальной памяти. На любительской системе и то и другое неактуально.」
На самом деле, в том числе способ почти мгновенного переключения контекста и средство отмены сурового требования к перемещаемости программ. Если ваша задача - снизить производительность БК12 до БК0011М - то нет вопросов, .
? Александр...@ - 02.04.2014 22:48
Ну если у вас есть крутые руководители и принято решение идти заветам самого Сеймура Крэя, то флаг вам в руки. Без меня точно.
? Дмитрий - 03.04.2014 00:05
>> где он вел свою работу
Вел. Но так и не довел. Не закончив одно, кинулся на другое. Тут будет тоже самое - бросит на полпути. :)
? Voland@ - 04.04.2014 00:37
>> Если ваша задача - снизить производительность БК12 до БК0011М - то нет вопросов
Не очень понятно, с чего это следует? И причем тут перемещаемость программ?
Переключение контекста к MMU никакого отношения не имеет, а точнее, с MMU контексты переключаются гораздо медленнее, ибо надо загружать таблицы другого процесса.
? Voland@ - 04.04.2014 00:38
>> Тут будет тоже самое - бросит на полпути. :)
Ну когда есть руководитель, задающий направление и протокол деятельности, то и работа перестает быть 100% завязанной на конкретного исполнителя.
? anonymous - 04.04.2014 08:58
「? Voland @ - сегодня 00:37 Не очень понятно, с чего это следует? И причем тут перемещаемость программ?」
Чтоб вы сами на свой вопрос ответили, опишите вкратце механизм параллельного выполнения двух программ с вычислением адресов внутри каждой при помощи математики, т.е. без таблиц адресов/смещений, которые можно было бы пересчитать при загрузке на выполнение такой программы.
「Переключение контекста к MMU никакого отношения не имеет, а точнее, с MMU контексты переключаются гораздо медленнее, ибо надо загружать таблицы другого процесса.」
Т.е. по-вашему перетаскивать десятки килобайт кода - быстрее, чем переписать несколько регистров, ок, вопросов больше нет.
? Voland@ - 04.04.2014 13:45
>> Т.е. по-вашему перетаскивать десятки килобайт кода - быстрее, чем переписать несколько регистров, ок, вопросов больше нет.
Ответ разработчика:
Откуда фантазии про мгновенное переключение контекста за счет MMU - ума не приложу. Посмотрите, сколько на x86 происходит работы именно в части MMU при переключении контекстов.
"перетаскивать десятки килобайт кода" надо не так часто, в процессе уплотнения памяти. А такая необходимость может возникнуть разве что из-за чрезмерной фрагментации. Существуют алгоритмы динамического выделения памяти, которые эту проблему решают и без пересылок, хотя за счет несколько большего ее расхода. А в процессе переключения контекстов никто ничего не перетаскивает, программы сидят по тем адресам, по которым их загрузили, все адреса настраиваются в момент загрузки кода.
? anonymous - 04.04.2014 15:20
Вы разработчика своего не вводите в заблуждение вырезанием контекста, условия были в первой части ответа озвучены. И создается такое впечатление, что он ни одной БКшной программы не видел неперемещаемой.
? Voland@ - 05.04.2014 00:02
Я обычно копирую ему сообщение без редактирования. Вот его очередной ответ, слегка редактированный:
Так понятно, что лучше быть богатым и здоровым. И чтобы MMU стоял и чтобы FPU и так далее и вообще получился бы VAX-11 в итоге. Еще и DDR2 поставить заодно, чтобы остальным тоже не обидно было; дело в том, что все эти вещи должны делаться под реального профессионального писателя ОС, который обосновал бы крайнюю необходимость ему MMU - вот тогда другое дело, была бы тема для серьезного обсуждения. А так, демагогия всё это.
? Александр...@ - 05.04.2014 00:42
Под конкретного писателя ОС - это круто. У вас там бутик процессоров открыт? :D VAX-11 вобще-то никто не требует. Я не знаю, что там и кто будет писать под это ОСь, но портировать что-то человеческое под процессор без MMU будет просто невозможно. За исключением встраиваемой экзотики и никому ненужных микроОС'ов.
? anonymous - 05.04.2014 09:53
Александр уже ответил вполне ясно. А я хотел бы ретро-вариант платы купить и может быть портировать на нее свою недо-ось чисто для себя, написанную под вм3/м8 в 90х по вдохновению от ОС9/ОС9к, с которыми на БЕСТА познакомился. М8-вариант с разделением К/Д так и не был дописан, т.к. добыть М8 для дома удалось совсем недавно, во второй половине 2000х - в качестве подарка. :) Оригинальная задумка реализует 64-килобайтовые виртуальные машины, с разделением времени процессора. Преврывание по смене контекста, в случае линейного исполнения кода в предыдущей и очередной задаче, довольствуется всего 37 пересылками, что пренебрежительно мало в сравнении с перетаскиванием кода неперемещаемой задачи, скомпилированной без возможности пересчета адресов, в системе без ДП, коих полно на БК. (Да тот же монитор БК0010 с областью векторов и системных переменных работает во многих случаях по относительной адресации, если сдвинуть его со 0100000 куда-нибудь - он потеряет работоспособность без пересборки)
? Voland@ - 20.04.2014 19:37
>> Оригинальная задумка реализует 64-килобайтовые виртуальные машины
Ответ разработчика:
похоже, что MMU там нужно, чтобы старые бинарики зачем-то грузить на любой адрес, не знаю зачем. Но для новых программ это как раз особого смысла не имеет, ибо их надо по-любому делать с возможностью настройки адресов при загрузке.
? anonymous - 20.04.2014 19:56
Но новых программ никто не будет писатЬ, с ваших же слов.
? Дмитрий - 02.05.2014 22:47
Нашел исходники компилятора Standard Pascal (ISO 7185), формирующий на выходе стандартный p-код (https://en.wikipedia.org/wiki/P-code_machine). Его еще надо дорабатывать, но уже сейчас простые программы работают. Сижу понемногу разбираюсь, буду писать компилятор этого р-кода в исполняемый код БК. Пока будет промежуточный этап с костылем в виде р-кода, затем, думаю, доработать его до графики и прочего. Либо на основе этого написать свой вариант.
<< Форум