Пишу компилятор с Оберона. Возник такой вопрос. Можно ли, на ваш взгляд, оставить из вещественных типов только REAL? Просто в этом случае реализация получается более простой. Кроме того, я думаю что в прикладных программах размера REAL вполне достаточно. Числа в 308(LONGREAL) степени нужны, я думаю, только в научных вычислениях. Ваши мнения.
А насколько больно от этого процессору? А то вдруг выигрыш от использования коротких типов невелик, а возможные беды от их неиспользования ощутимы. Если компилятор предполагается неигрушечный - наврняка кто-то в него рано или поздно засунет научные вычисления и... Я бы в такой ситуации скорее забил на тип REAL в пользу более длинного.
ухты какая тема. а чего не в прожектах? я так понял, планируется субсет? а какие требования? чего добавляете/чего опускаете? компиляция во что? (п-код/натив) (если п-код, то под какую вирт-машину?) фронтенд/бэкенд разделены? компиляция до обжа какого вида? планируется ли взаимодействие с С(++)? планируется ли компиляция + выполнение из памяти? (для встроеных применений былоб самое то) какие ограничения на размеры самого компилятора? планируется ли полноценная поддержка модульной структуры? планируется ли боунд контроль? и как? парсер на каком языке парсинга? или вручную? операторы будут только большими буквами? как там с потоками/синхронизацией/каналами? проект открыт/закрыт? если открыт или не-исключено-что-заопенсорсится, то на каком все ланге пишется? и под какую ось/компилер изначально? ну и вообще так беллетристики о. может я что спросить забыл
Я не сторонник громких заявлений. Можно на весь мир объявить что намерен написать аналог Visual Studio, организовывать всякие проекты и ничего не сделать. Не хочу вообще даже заикаться о чем-либо пока не будет сделано. Как говорят близзарды - "когда будет готово". Пишу не спеша. Нет. Полная реализация. Но с небольшими изменениями не меняющими суть языка. Натив. Под Windows. Компилятор будет создать .obj файлы COFF-формата. Проект будет открыт. Пишу на C. Нет. На C/C++ можно будет создать .obj файл, к нему дописать текстовый sym-файл(внешние объявления) и он будет неотличим от обычного модуля. Так планирую реализовать стандартную библиотеку на C. Нет. Надеюсь уложиться килобайт в сто. Да. Как предусмотрено спецификацией оберона. Планируется. Так ка это неотъемлемая часть оберона. Статический контроль типов и границ. Вручную. Это нетрудно. Всего-то 700-800 строк кода. Регистр букв свободный. Не понимаю смысла больших букв. Может со временем пойму. Вернуть не трудно. Спецификацией языка не предусмотрено.
Monogen нужен LONGREAL или нет - не твоя забота. Это стандарт языка. Раз уж пишешь компилятор, то давай реализовывай. а то недокомпилятор получится.
Monogen ну так как вы уже заикнулись, то сказав А, говорите и Б. а аналог визуал студии абсолютно никому не нужен. тем более, что их полно (хотя я могу не понимать что вы называете "аналог визуал студии") С это хорошо, С это праально. к слову "открыт" надо добавить еще и как открыт. кофф... а как формировать собираетесь? вынь - только вынь? или сразу будет писаться с возможностью переноса? опять же натив.. оптимайзер? бэкенд? вы сильны в этом? неправильное решение. оберон просто создан как язык для расширений. вся оберон-система это сплошные расширения на расширениях. поэтому, совсем не лишней была встраивательная фича. фактически это единственное, что может дать вашему проекту жизнь. не верите? это хорошо, но лучше меньше. вы ж оптимайзер писать не будете. почему и спросил. тогда вопрос - а как вы собираетесь организовывать межмодульные интерфейсы? подумайте. это самая тонкая часть модульных языков. чтоб можно было заменить какой нить модуль не дерагая все остальные итд. и чтоб интерфейс и протокол стыковки был максимально прост и универсален статического недостаточно. нужен и динамический. как его сделать без серьезных потерь в производительности? трудно или не трудно неважно. вручную - это самое паршивое решение из возможных. не думаете ли вы, что сразу вобьете все что решили и, что только можете захотеть, скам, лет через 5. и без ошибок. и с учетом того, что через нек время все перейдет на уникод, захочется иметь переменные в локальных буквах, изменится стандарт, понадобится слегка расширить под какуюнить задачу и проч. в свое время вирт придумал ебнф парсергенератор сосо. к нему в примерах есть несколько парсеров разных субсетов оберона. и даже один полный интертрепатор обероньего субсета. это не намек, боже упаси. для операторов. а для остальных кэйсзависмый? времена однопоточных програм прошли и боле не вернутся. можете использовать активобер-стандарт, можете расширить сами, вы ж все равно хотели? поддержка потоков/синхр/каналов на уровне языка это очень удобно и избавляет от многих кривомудрений
ну и использование гуглькода, раз уж проект изначально открыт, тоже может вылечить не одну болячку да, С какое? анси или на мс расширениях?
Monogen Вопрос совершенно несуразный. Вот если бы ты спросил, нужен ли тип Экстендед на 10 байт, можно было бы порассуждать. А без даблов невозможна никакая серьезная арифметика. 8 байт размер удобный, да и не пофигу ли вам, считает то сопроцессор?
persicum А чего тут рассуждать? На х86 это наиболее праведный тип, остальные - неполноценны по определению и интересны разве что для экономии памяти и обратной совместимости.
10 байт важны скорее для внутреннего представления чисел, а работа с ними в чистом виде нецелесообразна, сложнее адресация, проблемы с выравниванием, преимущества минимальны перед double, SSE/SSE2 работает без них. Так шо самый полноценный это double, а 10байт - менее ценен, а синглы это скорее для графики, когда скорость превыше всего а требования невысокие.
