Создание своего компилятора C а потом своей ОС на нем!!!
Тему видели и если есть чем поделиться пишите.
Если нет, но тема интересна смотрите за обновлениями форума.
PS :!!!:
Только одна просьба не засоряйте форум и не пишите не по делу, например не надо делиться своими впечатлениями(как отрицательными так и положительными).
Объяснять как и спрашивать пока нечего.
Тему видели и если есть чем поделиться пишите.
Если нет, но тема интересна смотрите за обновлениями форума.
PS :!!!:
Только одна просьба не засоряйте форум и не пишите не по делу, например не надо делиться своими впечатлениями(как отрицательными так и положительными).
Small C - неплохое начало для компилятора!
А зачем нужен новый если есть так много хороших компиляторов?
Для того чтобы писать свою ОС на Assembler требуется много времени. А так как я приверженец C, я бы хотел использовать его подходы к программированию. Но в стандартном C нет например передачи параметров функции через регистры или при написании ассемблерных вставок просто страшно работать со стеком когда не знаешь что напишет между вставками компилятор.
Короче задача такова:
Написать интерпретатор C-подобного языка(с моими требованиями к нему) на Assembler
Small C - неплохое начало для компилятора!
Да и еще хотел заметить, что Small C - скорее Java-подобный (если я не ошибаюсь) и уровень у него выше чем у стандартного C.
А из выше сказанного можно понять что я хочу написать язык ниже уровнем.
Извиняюсь. Уточняю тему.
Для того чтобы писать свою ОС на Assembler требуется много времени. А так как я приверженец C, я бы хотел использовать его подходы к программированию. Но в стандартном C нет например передачи параметров функции через регистры или при написании ассемблерных вставок просто страшно работать со стеком когда не знаешь что напишет между вставками компилятор.
Короче задача такова:
Написать интерпретатор C-подобного языка(с моими требованиями к нему) на Assembler
Watcom C - хорошо оптимизирует, прекрасно уживается с Ассемблером.
А передача параметров через регистры есть даже в Borland C++ (в 5.02 есть опция позволяющая использовать регистры) и в нем есть транслятор с C в Ассеблер.
В качестве языка, находящегося между Ассемблером и ЯВУ, можно использовать МАКРО-язык. Примером такого языка может служить Personal Forth (c) Light General. Если его модифицировать и отойти от концепции Forth'а то получится то, что надо.
Что касается предложеных компиляторов и языков.
Watcom C , Personal Forth (c) Light General, sphinx c--.
Я конечно сам буду искать информацию. Но если не сложно дайте хоть какие-нибудь ориентиры.
А на счет:
Мне нужна не опция. Надо чтобы нужные параметры паредавались через конкретные (назначенные мной регистры), как, например, в прерываниях. При этом чтобы была возможность как создавать, так и вызывать эти функции.
А в Borland C++ такого нельзя.
Прекрасно.
Что касается предложеных компиляторов и языков.
Watcom C , Personal Forth (c) Light General, sphinx c--.
Я конечно сам буду искать информацию. Но если не сложно дайте хоть какие-нибудь ориентиры.
Stealth Group (это по Personal Forth)
11.3 Регистровые процедуры.
Регистровые процедуры определяются, по умолчанию, при помощи
идентификатора, который не содержит символов строчных букв. Или же явным
указанием что это регистровая процедура с помощью ключевого слова fastcall.
Как уже было сказано, параметры (если они есть) для регистровой
процедуры передаются через регистры. Регистровые процедуры могут иметь не
более 6 параметров. Если параметры имеют тип int или word, регистры по
умолчанию используются в следующем порядке: AX, BX, CX, DX, DI, и SI.
Первые четыре параметра могут также иметь тип char или byte, в этом случае
задействуются регистры AL, BL, CL и DL соответственно. Любой из шести
параметров может иметь тип long, dword или float, тогда для него
используется регистр EAX, EBX, ECX, EDX, EDI, или ESI.
В следующем примере регистровая процедура с именем TOGETHER возвращает
значение типа word как результат умножения первого параметра, имеющего тип
word, на второй параметр того же типа:
word TOGETHER() /* AX = первый параметр, BX = второй параметр */
{
return (AX * BX);
}
В следующем примере регистровая процедура с именем SHOW_NUM, которая не
возвращает никакого значения, зато выводит на экран первый параметр
(имеющий тип int), затем разделительный знак в виде двоеточия :, а затем
второй параметр (имеющий тип byte) :
void SHOW_NUM () /* AX = первое число, BL = второе число */
{
$ PUSH BX
WRITEINT (int AX);
WRITE (':');
$ POP BX
WRITEWORD (BL);
}
Но если в процедуре сделать объявление порядка и типов используемых
регистров, то возможно произвольное использование регистров. Более подробно
об этом можно почитать в разделе об объявлениях параметров в регистровых
процедурах.
Для того, чтобы использовать регистровую процедуру как макрокоманду,
она должна быть объявлена как динамическая процедура. Динамические
процедуры описаны в следующем подразделе.
..ВЗЯТО из справки по spc--..
Если второе, то первое - точно не нужно.
Создать целую иерархию языков:
Assembler ->
Тот интерпретатор который я ищу ->
Возможно C++ ->
Внутрений язык опационной системы ->
Собственно опационная система.
Так чтобы с операционой системой можно было работать на разных уровнях.
Хотя венцом должен все-таки стать "Внутрений язык опационной системы", я считаю что без промежуточных ступеней не обойтись.
В конце (если до него дойдет) будет очень гибкая система программирования поддерживающая работу на всех уровня. Это и есть цель.
Идея создания хорошая, но ее не ждет большого будущего, если не исправить многих недочетов.
+
Доступно все, что можно сделать на Assembler и сделать это можно короче и проще.
-
Бесчисленое множество минусов признается в самой документации:
Совершенно не проработан приоритет операций(Почему просто не понятно!!!), вследствии чего просто неприятно работать с арифметическими действиями.
Не доработаны указатели.
Преобразование типов тоже не продумано (сделано просто чтобы было).
Неопределенность в арифметических выражениях при работе с регистрами. Если человек не знает всех особенностей компилятора, то в таких выражениях у него выдаются неправильные и непонятные ответы (для него). Что естественно нужно убирать.
Конечно это не все, но по мимо этого нет еще таких простых вещей, какие я бы делая это язык сделал.
Сам язык решает многие проблемы, которые меня интересуют и (признаю) является промежуточным между Assembler и C, но в нем нет ни гибкости C, ни простоты Assembler. Многие могут сказать, что это не возможно - может быть. Но можно сделать все гораздо логичнее и удобнее, чем это сделано.
Я скажу так: sphinx c-- это MacroAssembler с синтаксисом C.
Цель.
Создать целую иерархию языков:
Assembler ->
Тот интерпретатор который я ищу ->
Возможно C++ ->
Внутрений язык опационной системы ->
Собственно опационная система.
Так чтобы с операционой системой можно было работать на разных уровнях.
Хотя венцом должен все-таки стать "Внутрений язык опационной системы", я считаю что без промежуточных ступеней не обойтись.
В конце (если до него дойдет) будет очень гибкая система программирования поддерживающая работу на всех уровня. Это и есть цель.
Проведу аналогию со строительством.
Проблемма Вавилонской башни заключалась в сложности обменом информацией, т.к. Господь "смешал языки".
Твое же решение проблеммы, по аналогии, заключается в том, чтоб одному построить башню: обмениваться информацией ни с кем не надо - проблема решена.
Я это к тому, что написать компилятор языка высокого уровня, а тем более такого, как С++, в одиночку или даже небольшой командой практически невозможно. Тут уж либо осел умрет, либо царь...
Мое мнение по поводу sphinx c--.
Идея создания хорошая, но ее не ждет большого будущего, если не исправить многих недочетов.
+
Доступно все, что можно сделать на Assembler и сделать это можно короче и проще.
-
Бесчисленое множество минусов признается в самой документации:
Совершенно не проработан приоритет операций(Почему просто не понятно!!!), вследствии чего просто неприятно работать с арифметическими действиями.
Не доработаны указатели.
Преобразование типов тоже не продумано (сделано просто чтобы было).
Неопределенность в арифметических выражениях при работе с регистрами. Если человек не знает всех особенностей компилятора, то в таких выражениях у него выдаются неправильные и непонятные ответы (для него). Что естественно нужно убирать.
Конечно это не все, но по мимо этого нет еще таких простых вещей, какие я бы делая это язык сделал.
Сам язык решает многие проблемы, которые меня интересуют и (признаю) является промежуточным между Assembler и C, но в нем нет ни гибкости C, ни простоты Assembler. Многие могут сказать, что это не возможно - может быть. Но можно сделать все гораздо логичнее и удобнее, чем это сделано.
Я скажу так: sphinx c-- это MacroAssembler с синтаксисом C.
Насчет этого полностью согласен
Хорошая задумка, но не до конца осуществленная...
чтобы написать компилятор неплохо было бы уже иметь если не ОСь, то хотябы систему прерываний.
Поверьте, банальный printf() используя только БИОС бдет просто ужасен...И держать этот ужас в каждой программе нецелесообразно...
С другой стороны я надеюсь все-таки написать (или достать) первую ступень - тот компилятор который мы сейчас обсуждаем.
Сейчас я пытаюсь найти в Net ну хоть какую-нибудь стартовую точку, чтобы не писать все с нуля. Но чем дальше, тем больше понимаю что писать придется все самому.
PS
А на счет комманды:
Я учусь на программиста и среди сокурсников энтузиастов можно найти (правда не настолько, насколько хотелось бы знающих). Так что если знаешь людей увлекающихся данной проблемой - рекомендуй.
Я вообще по роду слубы к компиляторам отношения не имею , но подумал , вот что:
чтобы написать компилятор неплохо было бы уже иметь если не ОСь, то хотябы систему прерываний.
Поверьте, банальный printf() используя только БИОС бдет просто ужасен...И держать этот ужас в каждой программе нецелесообразно...
Хочу напомнить, что сам по себе printf() не относиться к языку - это просто библиотечная функция. Да и к самой программе она привязываится не на стадии компиляции, а во время линкования.
А я хочу создать компилятор, и выдавать он будет *.obj файлы (или *.asm).
Да и еще - если я не ошибаюсь даже компилятор C не вставляет в код прерываний. А уж тем более язык ниже уровнем этого не должен делать.
PS
Хотя признаю на счет прерываний ты прав, но ты видимо не понял - я создаю инструментарий для создания ОС, а не ею самой(по крайней мере на данный момент).
Объяснять как и спрашивать пока нечего.
Тему видели и если есть чем поделиться пишите.
Если нет, но тема интересна смотрите за обновлениями форума.
PS :!!!:
Только одна просьба не засоряйте форум и не пишите не по делу, например не надо делиться своими впечатлениями(как отрицательными так и положительными).
Зачем писать ОС на своем новом языке, если для написания ОС можно взять GNU C & GNU as, а потом написать сиху, на которой люди уже будут под твоей ОС проги писать?
PS: Подскажите, где можно взять LL(1) грамматику языка Си, а то мне самому влом делать.
Зачем писать ОС на своем новом языке, если для написания ОС можно взять GNU C & GNU as, а потом написать сиху, на которой люди уже будут под твоей ОС проги писать?
PS: Подскажите, где можно взять LL(1) грамматику языка Си, а то мне самому влом делать.
Писать свой компилер целесообразно только если он будет отличаться (желательно в лучшую сторону) от того, что есть сейчас. Не обязательно это должен быть чистый С.
Насчет инструмента для генерации компилятора очень рекомендую cocor (инфу по нему можно в инете достать в большом количестве. К нему прилагаются грамматики многих известных языков, включая С). С его помощью можно за пару дней/недель ;) написать транслятор с ЯВУ в асм или еще куда. Если писать компилер для своей ОС, то нет необходимости придерживаться формата PE-COFF или еще какого. Поэтому задача упрощается (нет необходимости вникать в формать PE :)
Зачем писать ОС на своем новом языке, если для написания ОС можно взять GNU C & GNU as, а потом написать сиху, на которой люди уже будут под твоей ОС проги писать?
PS: Подскажите, где можно взять LL(1) грамматику языка Си, а то мне самому влом делать.
Поэтому задача упрощается (нет необходимости вникать в формать PE :)
Зачем же сразу PE?
Я не видел формата лучшего, чем ELF, тем более, что он и 64-битный формат кода поддерживает. Из тех ОС(самописных) что я видел, где-то 70% используют именно его. Да и загрузчик для него достаточно простой.
Зачем же сразу PE?
Я не видел формата лучшего, чем ELF, тем более, что он и 64-битный формат кода поддерживает. Из тех ОС(самописных) что я видел, где-то 70% используют именно его. Да и загрузчик для него достаточно простой.
Можно и ELF
Если сильно упростить условия - например, принять во внимание ограниченное кол-во переменных в программе, выделять лексемы без использования буферизации, ограничиться малым кол-вом управляющих структур и др. - то тогда, вероятно, задача написания своего интерпретатора разрешима. Но это будет скорее игрушка, чем практически востребованное решение.
Соверую почитать Серебрякова "Лекции по конструированию компиляторов" - там много написано по теме.
Совершенно ясно, что написать свой компилятор одному вручную - задача весьма непростая. Попробуйте упростить задачу и написать простой интерпретатор - увидите все сложности.
Уже увидел. Кто еще пробовал писать компилятор??? :) У меня дальше разбора арифметического выражения методом рекурсивного спуска дело не дошло, хотя у меня и инфа на этот счет есть.
Я считаю, было бы проще добавить в свою ОСь поддержку POSIX и либу yacc, а потом туда портировать FreeBSD-ишный сишный компилятор.
Уже увидел. Кто еще пробовал писать компилятор??? :) У меня дальше разбора арифметического выражения методом рекурсивного спуска дело не дошло, хотя у меня и инфа на этот счет есть.
Я считаю, было бы проще добавить в свою ОСь поддержку POSIX и либу yacc, а потом туда портировать FreeBSD-ишный сишный компилятор.
Разбор арифметических выражений методом рекурсивного спуска - подход, который подходит для ручного кодирования. На практике используют другие методы.
Думаю, стоит посмотреть исходники GCC, чтобы понять всю сложность создаваемого компилятора.
Разбор арифметических выражений методом рекурсивного спуска - подход, который подходит для ручного кодирования. На практике используют другие методы.
Думаю, стоит посмотреть исходники GCC, чтобы понять всю сложность создаваемого компилятора.
А в чем, собственно, сложность создания компилятора? По-моему единственный сложный момент - это генерация кода, точнее генерация не просто кода, а оптимального кода. А разбор текста и проч. - это все ерунда. К тому же редко кто пишет вручную лексеры и парсеры...
А в чем, собственно, сложность создания компилятора? По-моему единственный сложный момент - это генерация кода, точнее генерация не просто кода, а оптимального кода. А разбор текста и проч. - это все ерунда. К тому же редко кто пишет вручную лексеры и парсеры...
Не знаю - автоматически код не создавал. Перефразируя, могу ответить - редко какой из компиляторов написан с использованием автоматизир. систем.
Сложностей-то и подходов к решению - пруд пруди. Важно решить какой наиболее эффективный подход взять для решения наиболее важных проблемы.
Практически сложно реализовать наиболее быстрый алгоритмы выделения лексем, организации таблиц идентификаторов и их атрибутов с возможностью быстрого поиска и вставки, представления выражений в виде некоей структуры.
Оптимизация и внутр. представление взаимосвязаны.
Если сможешь организовать представление выражения в виде простой структуры - сможешь найти простой путь для оптимизации этого выражения.
Разбор арифметических выражений методом рекурсивного спуска - подход, который подходит для ручного кодирования. На практике используют другие методы.
Думаю, стоит посмотреть исходники GCC, чтобы понять всю сложность создаваемого компилятора.
Согласен, LL(1) используется почти во всех нормальных компиляторах.
А в чем, собственно, сложность создания компилятора? По-моему единственный сложный момент - это генерация кода, точнее генерация не просто кода, а оптимального кода. А разбор текста и проч. - это все ерунда. К тому же редко кто пишет вручную лексеры и парсеры...
Во первых, компиляторы, использующие разбор методом рекурсивного спуска реально не используются из-за огромного количества требуемой памяти и времени. Если писать компилятор LL(1) грамматики то надо еще эту грамматику составить - далеко не каждая грамматика является LL(1) грамматикой.
По поводу автоматического построения компиляторов: они очень широко используются (особенно под UNIX). Например - MySQL, shell (sh,csh), ... Вообщем читайте доку по YACC и LALR грамматикам.
теория есть в
А.Ю. Молчанов "Системное программное обеспечение"
изд. Питер
Народ а нахрена вам это все надо? Что вы нового хотите придумать.Велосипед заного изобретать?
А ты попробуй сам велосипед изобрести :)
А вообще практика построения компиляторов никому не помешает.
А ты попробуй сам велосипед изобрести :)
А вообще практика построения компиляторов никому не помешает.
Конечно, это так.
Только зачем ещё и компилятор самому писать, когда есть прекрасные языки - C#, C++, да тот же Delphi, незаслуженно отвергаемый. Если писать компилятор, а потом ещё и систему, то голова может лопнуть, не выдержать нагрузки, потому что слишком много проблем возникнет. Я писал бы систему на C# и, где только можно, на Дельфях. Потом систему, доведённую до нужной кондиции, можно и продавать.
Можно сделать систему, работающую в реальном времени.
... Я писал бы систему на C# и, где только можно, на Дельфях. Потом систему, доведённую до нужной кондиции, можно и продавать.
Можно сделать систему, работающую в реальном времени.
ОС на С#????? Не, ну что, я на Java ось писал... :)
Дельфи (как язык) для меня понятнее C.
А ты уверен, что хорошо знаешь Дельфи?
Низкоуровневый код ядра на нем, разумеется, не напишешь. А вот все остальное - пожалуйста. Вариант такой: берется независимая ОС с форматом исполняемого модуля PE, под нее адаптируется RTL (System.pas) и пиши - не хочу.
Возможно, придется сильно доставать разработчиков соответствующей ОС. Из известных мне формат PE у SkyOS, UzhOS, Miraculix, ExpressOS. Ищи поиском. Будут спрашивать - я тебе ничего не говорил. ;)
Кстати, есть еще разработки ОС на Паскале, как правило, FPC. Например, широко известная в узких кругах разработка Алексея Фрузе или украинская StreamOS.
А ты уверен, что хорошо знаешь Дельфи?
Уверен абсолютно.
Низкоуровневый код ядра на нем, разумеется, не напишешь. А вот все остальное - пожалуйста.
Ну что же, ради написания кода ядра можно помучаться с ассемблером... хотя выучить его для меня сложно. Кстати, какие сейчас самые последние среды программирования на ассемблере? Хотелось бы что-то вроде Delphi (в смысле, такого же типа редактор), но с компилятором Assembler. Выучить, в принципе, можно... Я пытался его выучить по книге Фаронова (Turbo Pascal), даже почти выучил, но потом появилась Delphi, и я про Паскаль забыл, а в ассемблере под Windows много чего делается по-другому...
Да, и ещё: ХОРОШУЮ книгу по ассемблеру (для Форточек) не посоветуете? Хотелось бы написать свою систему, да такую, чтобы под ней работали программы для Linux, FreeBSD и (не знаю, возможно ли такое в принципе) Windows.
Да, и ещё: ХОРОШУЮ книгу по ассемблеру (для Форточек) не посоветуете? Хотелось бы написать свою систему, да такую, чтобы под ней работали программы для Linux, FreeBSD и (не знаю, возможно ли такое в принципе) Windows.
Уверяю тебя, как только ты начнешь понимать работу компа и освоишь ассемблер, тебе расхочется писать оси и прочую мурню ;)
Уверяю тебя, как только ты начнешь понимать работу компа и освоишь ассемблер, тебе расхочется писать оси и прочую мурню ;)
Я, конечно, понимаю, что Ассемблер он и есть Ассемблер, как ни крути, но написать собственную ОС, не уступающую в надёжности Linux или новейшей Windows (только не 64-битную), мне очень хочется. Как работает комп, я очень хорошо знаю. Не хватает знаний Ассемблера. C - язык "корявый", и пока что-то он не учится. А вот Ассемблер можно было бы выучить только ради написания ядра ОС.
Помоему в действительности что можно сделать реально так это посмотреть исходники готовой оси и на ее основе разбиратся, дорабатывать, придумывать что то новое в том или ином направлении, а не писать ОС с нуля - на мой взгляд тратя таким образом время впустую.
К стати : в QNX большая дырка обнаружилась - выполнение пользовательского кода в 0 кольце . Есть боольшая вероятность что таже дыра во всех линухах есть (про вин вообще молчу ). :) :)