Oberon space
General Category => Общий раздел => Тема начата: valexey от Март 21, 2011, 09:14:28 am
-
Появился новый компилятор для языка программирования Oberon-07M. "M" означает, что язык разширен, в частности разрешены одномерные динамические массивы.
Разработчиком данного компилятора являюсь я сам. Компилятор изначально разрабатывался на Component Pascal, после чего исходные тексты были немного изменены и скомпилированы, самим компилятором Oberon-07M.
Компилятор можно скачать с сайта http://ExaProg.com (http://ExaProg.com). Сайт пока очень простой. В дальнейшем планирую сделать его более красивым, выложить туда документацию по компилятору.
Если будут вопросы или найдете ошибки, то пишите мне на почту, адрес почты указан на сайте: http://ExaProg.com (http://ExaProg.com).
-
Попробовал. Под Win7 все собралось (хотя компилирует конечно несколько задумчиво для таких объемов). То есть Hello World даже работает. Попробовал сборщик мусора, сборщик мусора явно лучше чем во всех виденых мною реализациях Оберонов (ну, если не брать в рассчет тот, что в gpcp и прочих живущих в чужих виртуальных машинах).
Однако имеются вопросы:
1) Как у этого сборщика мусора с многопоточностью? То есть если я засандолю несколько потоков, не попортит ли мне сборщик мусора что-нибудь?
2) Что с поддержкой 64 бит?
3) Документация по компилятору какая-нибудь будет?
Ну и предложение — таки именовать исходники не как .txt, а как .ob7 например. Чтобы визуально различались.
-
...возможность использовать компиляторы вариантов Оберона из-под ББ, чтобы создавались бинарники стандартного ББ-формата.
Не вижу (пока) причин, почему такие бинарники не могли бы бесшовно вписываться в среду ББ.
Согласен. Исходя из общих соображений, по-моему, достаточно переделать только ББй сканер/парсер КП под О7, плюс склепать какую-то переключалку.
Проблем масса. Другой рантайм, например. Другой сборщик мусора. Другая семантика, другие типы. Например Оберон-07 ничего не знает про процедуры связанные с типом записи. Ничего не знает про то, что некоторые записи нельзя расширять, иерархия записей в Обероне-07 не имеет единого корня, в отличае от КП. То есть проблемы будут со интеграцией.
Вот если бы ББ был построен на Обероне, то сверху насадить КП было бы много проще, чем сейчас.
-
Ах да, еще вопрос — будет ли портабельный вариант компилятора? То есть для невинды, а posix'а (linux/bsd/macos x/qnx/solaris etc).
-
...возможность использовать компиляторы вариантов Оберона из-под ББ, чтобы создавались бинарники стандартного ББ-формата.
Не вижу (пока) причин, почему такие бинарники не могли бы бесшовно вписываться в среду ББ.
Согласен. Исходя из общих соображений, по-моему, достаточно переделать только ББй сканер/парсер КП под О7, плюс склепать какую-то переключалку.
Проблем масса. Другой рантайм, например. Другой сборщик мусора. Другая семантика, другие типы. Например Оберон-07 ничего не знает про процедуры связанные с типом записи. Ничего не знает про то, что некоторые записи нельзя расширять, иерархия записей в Обероне-07 не имеет единого корня, в отличае от КП. То есть проблемы будут со интеграцией.
Вот если бы ББ был построен на Обероне, то сверху насадить КП было бы много проще, чем сейчас.
Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе 07 ..
-
Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе 07 ..
Но это и не самый плохой вариант. Опыт опять таки. Алсо, никто не мешает желающим разрабатывать новый язык базового уровня на базе 07, таки уже его разрабатывать (на уровне спек). И когда там что-то будет, можно и компилятор сделать, благо опыт уже будет.
-
Oднако имеются вопросы:
1) Как у этого сборщика мусора с многопоточностью? То есть если я засандолю несколько потоков, не попортит ли мне сборщик мусора что-нибудь?
2) Что с поддержкой 64 бит?
3) Документация по компилятору какая-нибудь будет?
Ну и предложение — таки именовать исходники не как .txt, а как .ob7 например. Чтобы визуально различались.
Компилятор расчитан на однопоточные программы, также как и ББ.
Компилятор генерирует 32 битный код, в планах есть сделать 64-битную версию компилятора.
Документация будет в ближашие дни.
Насчет расширения согласен, что txt не очень удачно, что лучше ob7. В принципе вы сами можете переименовать файлы и изменить в bat файле расширение.
-
Да, уточню конфигурацию где у меня все заработало: Windows 7 32 bit rus.
-
Однопоточность это печально… Ну да ладно.
И еще вопрос по разработке компилятора – есть ли у набор компиляторных тестов?
-
Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе 07 ..
Но это и не самый плохой вариант. Опыт опять таки. Алсо, никто не мешает желающим разрабатывать новый язык базового уровня на базе 07, таки уже его разрабатывать (на уровне спек). И когда там что-то будет, можно и компилятор сделать, благо опыт уже будет.
Что вы имеете в виду под фичиванием?
То что я добавил динамические массивы. Я размышлял над тем нужны ли они, можно ли обойтись только указателями на запись, но пришел к выводу, что в некоторых случаях несколько блоков фиксированного размера не могут заменить одного большого массива. Например, когда требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.
Кроме того, никто не запрещает не пользоваться динамическими массивами, если вы не хотите, а программировать так, как будто их нет.
-
Однопоточность это печально… Ну да ладно.
И еще вопрос по разработке компилятора – есть ли у набор компиляторных тестов?
У меня есть свои тесты на которых я тестировал, но выложить их пока не могу, их надо еще причёсывать.
-
Компилятор генерирует 32 битный код, в планах есть сделать 64-битную версию компилятора.
64 битную версию компилятора, или компилятор генерирующий 64битный код? Впрочем, поскольку он компилирует сам себя, то видимо и то и это.
Однако вопрос возникает – как быть с типами данных? В Обероне-07 размеры всех примитивных типов четко расписаны. То есть видимо придется расширять язык новыми типами вроде LONGINT, ну и чтобы NEW(arr, len) len принимал типа LONGINT. Жаль что в Обероне-07 нельзя создавать псевдонимы для примитивных типов, это помогло бы в данном случае.
-
Компилятор генерирует 32 битный код, в планах есть сделать 64-битную версию компилятора.
64 битную версию компилятора, или компилятор генерирующий 64битный код? Впрочем, поскольку он компилирует сам себя, то видимо и то и это.
Однако вопрос возникает – как быть с типами данных? В Обероне-07 размеры всех примитивных типов четко расписаны. То есть видимо придется расширять язык новыми типами вроде LONGINT, ну и чтобы NEW(arr, len) len принимал типа LONGINT. Жаль что в Обероне-07 нельзя создавать псевдонимы для примитивных типов, это помогло бы в данном случае.
Как я себе представляю 64 битную весию, что тип INTEGER и указатели будут занимать 64 бита, и не будет необходимости в другом типе данных. Но об этом еще пока рано думать, надо сначала обкатать эту версию.
-
То что я добавил динамические массивы. Я размышлял над тем нужны ли они, можно ли обойтись только указателями на запись, но пришел к выводу, что в некоторых случаях несколько блоков фиксированного размера не могут заменить одного большого массива. Например, когда требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.
На самом деле можно и без них. Например см. http://en.wikipedia.org/wiki/VList
Ясно что нам для реализации VList'a произвольного размера потребуется 32 типа массивов фиксированного размера оберона-07.
-
Как я себе представляю 64 битную весию, что тип INTEGER и указатели будут занимать 64 бита, и не будет необходимости в другом типе данных. Но об этом еще пока рано думать, надо сначала обкатать эту версию.
Это, вообще говоря, нарушит совместимость с Оберон-07 и будет явно противоречить спеке на оный Оберон-07. Но наверное да, пока рано об этом.
-
Есть ощушение, что Rifat пошел по пути фичивания 07- на практике, это мало что добавляет к сфере его использования -ИМХО Не самый лучший вариант, целесообразнее разработать новый язык базового уровня на основе 07 ..
Но это и не самый плохой вариант. Опыт опять таки. Алсо, никто не мешает желающим разрабатывать новый язык базового уровня на базе 07, таки уже его разрабатывать (на уровне спек). И когда там что-то будет, можно и компилятор сделать, благо опыт уже будет.
Что вы имеете в виду под фичиванием?
То что я добавил динамические массивы. Я размышлял над тем нужны ли они, можно ли обойтись только указателями на запись, но пришел к выводу, что в некоторых случаях несколько блоков фиксированного размера не могут заменить одного большого массива. Например, когда требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.
Кроме того, никто не запрещает не пользоваться динамическими массивами, если вы не хотите, а программировать так, как будто их нет.
Это и называется фичиванием - недостаток такого подхода заключается в том, что вы фичуете (добавляете особенности) изходя из текущих нужд - есть очень большая вероятность что они (фичи) будут неэффективными и малоиспользуемыми в предпологаемой области применения ЯП. Проще, вы можете ответить ДЛЯ ЧЕГО и для КОГО вы создаете ЯП. Кроме того, описать его общее место в области описания моделируемых систем общего вида... ну например, в контексте схемы предложенной в топике про "Многоуровневый ЯП на основе ОБЕРОНА".
-
На самом деле можно и без них. Например см. http://en.wikipedia.org/wiki/VList
Ясно что нам для реализации VList'a произвольного размера потребуется 32 типа массивов фиксированного размера оберона-07.
А вот чтобы ответить грамотно на то нужно это или нет - необходимо действовать в соответствии с какой то моделью и планом см. сообщение выше.. (и даже просто, для того что бы грамотно и продуктивно обсуждать топик...)
-
А вот чтобы ответить грамотно на то нужно это или нет - необходимо действовать в соответствии с какой то моделью и планом см. сообщение выше.. (и даже просто, для того что бы грамотно и продуктивно обсуждать топик...)
Наверно мну не правильно понял народ – я показал возможное решение данной очень конкретной задачи которое не использует массивы неизвестного размера на этапе компиляции. Вот эта задача:
требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.
Про нужность или не нужность оных массивов в языке я не говорил.
-
Наверно мну не правильно понял народ – я показал возможное решение данной очень конкретной задачи которое не использует массивы неизвестного размера на этапе компиляции. Вот эта задача:
А я говорю про то, что возможным пользователям языка может просто не понядобиться решать эту задачу...
-
То что я добавил динамические массивы. Я размышлял над тем нужны ли они, можно ли обойтись только указателями на запись, но пришел к выводу, что в некоторых случаях несколько блоков фиксированного размера не могут заменить одного большого массива. Например, когда требуется за логарифмическое время находить какое-нибудь значение в большом объеме данных, при помощи бинарного поиска.
На самом деле можно и без них. Например см. http://en.wikipedia.org/wiki/VList
Ясно что нам для реализации VList'a произвольного размера потребуется 32 типа массивов фиксированного размера оберона-07.
Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.
-
А я говорю про то, что возможным пользователям языка может просто не понядобиться решать эту задачу...
Ну коль компилятор под винду, то встраиваемые решения отпадают, отпадает, по хорошему, и сервер. Остается десктоп, для десктопа такие задачи встречаются.
-
Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.
А вот это уже да, аргумент. Можно пример такой WinAPI функции? А то на вскидку ничего не припоминается.
-
Появился новый компилятор для языка программирования Oberon-07M. "M" означает, что язык разширен, в частности разрешены одномерные динамические массивы.
Благодарю за приятную новость о выпуске Вашего компилятора! :)
Раз язык изменился, то должно быть новое описалово. Планируется ли его публикация?
Не могли бы Вы по пунктам перечислить здесь все новшества, с короткими комментариями.
-
А я говорю про то, что возможным пользователям языка может просто не понядобиться решать эту задачу...
Ну коль компилятор под винду, то встраиваемые решения отпадают, отпадает, по хорошему, и сервер. Остается десктоп, для десктопа такие задачи встречаются.
Алексей язык это нечто больше чем компилятор .... ;) суть то вопроса не в этом... я предлагаю просто для начала - определиться с местом ЯП, сферой применения, затем с пользователем. - а все остальное выползет на автомате....
-
Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.
А вот это уже да, аргумент. Можно пример такой WinAPI функции? А то на вскидку ничего не припоминается.
На вскидку GetFileSecurity, есть еще много других, но надо их искать.
-
Появился новый компилятор для языка программирования Oberon-07M. "M" означает, что язык разширен, в частности разрешены одномерные динамические массивы.
Благодарю за приятную новость о выпуске Вашего компилятора! :)
Раз язык изменился, то должно быть новое описалово. Планируется ли его публикация?
Не могли бы Вы по пунктам перечислить здесь все новшества, с короткими комментариями.
Описание изменений планируется в ближайшие несколько дней. Когда будет готово, файл будет выложен на сайте.
-
На вскидку GetFileSecurity, есть еще много других, но надо их искать.
BOOL WINAPI GetFileSecurity(
__in LPCTSTR lpFileName,
__in SECURITY_INFORMATION RequestedInformation,
__out_opt PSECURITY_DESCRIPTOR pSecurityDescriptor,
__in DWORD nLength,
__out LPDWORD lpnLengthNeeded
);
lpFileName [in]
A pointer to a null-terminated string that specifies the file or directory for which security information is retrieved.
RequestedInformation [in]
A SECURITY_INFORMATION value that identifies the security information being requested.
pSecurityDescriptor [out, optional]
A pointer to a buffer that receives a copy of the security descriptor of the object specified by the lpFileName parameter. The calling process must have permission to view the specified aspects of the object's security status. The SECURITY_DESCRIPTOR structure is returned in self-relative format.
nLength [in]
Specifies the size, in bytes, of the buffer pointed to by the pSecurityDescriptor parameter.
lpnLengthNeeded [out]
A pointer to the variable that receives the number of bytes necessary to store the complete security descriptor. If the returned number of bytes is less than or equal to nLength, the entire security descriptor is returned in the output buffer; otherwise, none of the descriptor is returned.
А где тут указатель на массив размер которого в общем случае не известен?
То есть что мы тут выгадаем, если у нам будут массивы размера неизвестного на этапе компиляции?
-
Поясню на всякий случай – мы тут размер не знаем ни на этапе компиляции, ни на этапе исполнения. Если после вызова функции нам оно скажет что "нишмогла, не поместилась в буфер даденого размера", то стратегия проста – удваиваем размер буфера и пробуем снова. Для удваивания буфера, как я заметил выше, массивы с размером неизвестным на этапе компиляции не нужны.
-
В принципе возможно, конечно, заранее определить несколько буферов, так что размер следующего в два раза больше предыдущего, вплоть до максимального объема памяти. И использовать буфер, который подходит. Но будет ли это красивым решением?
-
А таки тормоз, да. Ведь обычный сценарий работы с этой функцией таков:
//
// STEP 2: Get security descriptor (SD) of the file specified.
//
fAPISuccess = GetFileSecurity(lpszFileName,
secInfo, pFileSD, 0, &cbFileSD);
// API should have failed with insufficient buffer.
if (fAPISuccess)
__leave;
else if (GetLastError() != ERROR_INSUFFICIENT_BUFFER) {
_tprintf(TEXT("GetFileSecurity() failed. Error %d\\n"),
GetLastError());
__leave;
}
pFileSD = myheapalloc(cbFileSD);
if (!pFileSD) {
_tprintf(TEXT("HeapAlloc() failed. Error %d\\n"), GetLastError());
__leave;
}
fAPISuccess = GetFileSecurity(lpszFileName,
secInfo, pFileSD, cbFileSD, &cbFileSD);
if (!fAPISuccess) {
_tprintf(TEXT("GetFileSecurity() failed. Error %d\\n"),
GetLastError());
__leave;
}
То есть, вначале гарантировано оно падает с сообщением "мало памяти" но при этом говорит сколько памяти ей нужно, мы создаем буфер, второй раз вызываем уже с созданым буфером и оно уже должно отработать как надо (при условии что при втором вызове требуемый размер еще не увеличился).
Впрочем, я не вижу необходимости менять язык для поддержки массивов неизвестной на этапе компиляции длины.
Делается это очень просто:
CONST
unknown = 0;
...
VAR
arr : POINTER TO ARRAY unknown OF CHAR;
...
arr := MALLOC(len); (* :-) *)
-
Делается это очень просто:
CONST
unknown = 0;
...
VAR
arr : POINTER TO ARRAY unknown OF CHAR;
...
arr := MALLOC(len); (* :-) *)
Плохое решение - почему 0 (и нафига это нужно) (лучше POINTER TO ARRAY OF CHAR ), что это такое малок - вид специальной пропер функции (а как мусорка, к тому же уже есть NEW)... нет уж лучше новый тип ввести, другое дело если new -придать "функциональный" вид - эта идея мне гораздо более нравится...
-
Плохое решение - почему 0 (и нафига это нужно) (лучше POINTER TO ARRAY OF CHAR ), что это такое малок - вид специальной пропер функции (а как мусорка, к тому же уже есть NEW)... нет уж лучше новый тип ввести, другое дело если new -придать "функциональный" вид - эта идея мне гораздо более нравится...
0 потому, что 0. Ибо размер там от 0 и до куда хочешь. Это стандартный прием, в общем то.
MALLOC это низкоуровневая функция которая непосредственно из системы выбивает память. Конечно лучше на NEW заменить.
Нет, добавлять еще одну спецформу в язык я не хочу, ибо хочу чтобы язык был тот же самый. А по Оберону-07 констркция POINTER TO ARRAY не валидна.
NEW придать фунциональный вид не получится, вообще NEW это не процедура а черти что – результат работы зависит от типов аргументов, что, вообще говоря, не характерно для обычных процедур в обероне (перегружать их ведь нелья). Если сделать NEW в виде функциональном, то получится совсем снос мозга – результат работы функции будет зависеть от типа переменной куда записывается результат возвращенный функцией.
-
Плохое решение - почему 0 (и нафига это нужно) (лучше POINTER TO ARRAY OF CHAR ), что это такое малок - вид специальной пропер функции (а как мусорка, к тому же уже есть NEW)... нет уж лучше новый тип ввести, другое дело если new -придать "функциональный" вид - эта идея мне гораздо более нравится...
0 потому, что 0. Ибо размер там от 0 и до куда хочешь. Это стандартный прием, в общем то.
MALLOC это низкоуровневая функция которая непосредственно из системы выбивает память. Конечно лучше на NEW заменить.
Нет, добавлять еще одну спецформу в язык я не хочу, ибо хочу чтобы язык был тот же самый. А по Оберону-07 констркция POINTER TO ARRAY не валидна.
NEW придать фунциональный вид не получится, вообще NEW это не процедура а черти что – результат работы зависит от типов аргументов, что, вообще говоря, не характерно для обычных процедур в обероне (перегружать их ведь нелья). Если сделать NEW в виде функциональном, то получится совсем снос мозга – результат работы функции будет зависеть от типа переменной куда записывается результат возвращенный функцией.
1 А если будет 10 то что это даст ;) ведь в малоке у вас другой параметр ?
2 Что такое малок в си я знаю..
3 лучше бы она была валидной...
4 По этому такого рода функуции\\процедуры называются proper, а вот насчет смысла мозгов я не понимаю... - в оберонах new - oчень простой смысл, создание динамического обьекта ИЗВЕСТНОГО ТИПА и передача адреса его в соответствующую переменную (указатель), над указателями разрешены только операции сравнения и присваивания (это не си) - или я ошибаюсь?
-
1 А если будет 10 то что это даст ;) ведь в малоке у вас другой параметр ?
10 не даст, а отнимет :-) Отобьет понималку на счет того, что размер массива не известен на этапе компиляции. То есть я могу создать экземпляр массива размером 10, но не могу создать его размером 0. Таким образом 0 это явный признак того, что массив будет неизвестного (на этапе компиляции) размера. В Си это очень часто применяется.
4 По этому такого рода функуции\\процедуры называются proper, а вот насчет смысла мозгов я не понимаю... - в оберонах new - oчень простой смысл, создание динамического обьекта ИЗВЕСТНОГО ТИПА и передача адреса его в соответствующую переменную (указатель), над указателями разрешены только операции сравнения и присваивания (это не си) - или я ошибаюсь?
arr := NEW(len);
Какой именно тут NEW будет вызван будет зависеть от типа arr. Вот в этом снос мозга. Это сильно не обычная функция получается. Очень не обычная. NEW как proper procedure конечно тоже не обычная. Который NEW будет вызван там зависит от типа аргумента. Однако такая перегрузка процедур-функций более привычна, ибо она встречается повсеместно в других языках.
-
Конечно можно и так написать:
CONST
unknown = 0;
...
VAR
arr : POINTER TO ARRAY unknown OF CHAR;
...
NEW(arr, len);
Я некий левый MALLOC использовал лишь для того, чтобы показать, что это все можно легко сделать библиотекой а не частью рантайма/компилятора.
Кстати, вот что было бы точно полезно ввести, так это ещё одну встроенную функцию: TYPEID(Val) и TYPEID(Type), функция должна вернуть целочисленное уникальное значение для даденого типа соответственно переменной, или типа.
То есть:
intTypeId0 : INTEGER;
intTypeId1 : INTEGER;
intTypeId0 := TYPEID(INTEGER);
intTypeId1 := TYPEID(intTypeId1);
ASSERT(intTypeId0 = intTypeId1);
Это позволит писать собственные библиотечные аллокаторы.
-
Хотя лучше не INTEGER возвращать, а ссылку на структуру с описанием данного типа. Сравнивать их все равно можно, а вот бесполезные операции вроде <,>,+ и так далее, для записей бесполезны. Алсо можно будет например узнать подробности, вроде имени типа и его параметров (если тип параметризуем, как например массив).
-
Хотя нет, я ошибся, этого не достаточно для того, чтобы можно было написать аллокатор в Обероне-07 и удобно им пользоваться.
-
arr := NEW(len);
Какой именно тут NEW будет вызван будет зависеть от типа arr. Вот в этом снос мозга. Это сильно не обычная функция получается. Очень не обычная. NEW как proper procedure конечно тоже не обычная. Который NEW будет вызван там зависит от типа аргумента. Однако такая перегрузка процедур-функций более привычна, ибо она встречается повсеместно в других языках.
Это снос мозга сишника -в си с указателями можно сделать многое... в обероне только присваивать и сравнивать ("равно" и "неравно") с NIL и значением переменной-указателя ТАКОГО же типа... впрочем я повторяюсь... :)
-
Хотя нет, я ошибся, этого не достаточно для того, чтобы можно было написать аллокатор в Обероне-07 и удобно им пользоваться.
А вот это вроде против философии мусоросборщика... если этим заниматься - тогда нужно четко представлять нафиг и кому это нужно...
-
arr := NEW(len);
Какой именно тут NEW будет вызван будет зависеть от типа arr. Вот в этом снос мозга. Это сильно не обычная функция получается. Очень не обычная. NEW как proper procedure конечно тоже не обычная. Который NEW будет вызван там зависит от типа аргумента. Однако такая перегрузка процедур-функций более привычна, ибо она встречается повсеместно в других языках.
Это снос мозга сишника -в си с указателями можно сделать многое... в обероне только присваивать и сравнивать ("равно" и "неравно") с NIL и значением переменной-указателя ТАКОГО же типа... впрочем я повторяюсь... :)
Про ограничение операций над указателями тут вообще не в тему. Замени arr на любой другой тип (INTEGER, BOOL, RECORD какой-нибудь (не ссылка на него)) – ничего не изменится. Крышесном останется.
-
Хотя нет, я ошибся, этого не достаточно для того, чтобы можно было написать аллокатор в Обероне-07 и удобно им пользоваться.
А вот это вроде против философии мусоросборщика... если этим заниматься - тогда нужно четко представлять нафиг и кому это нужно...
Пулы мусоросборщику никак не противоречат. Потому как нужны иногда. Особенно в задачах критичных по скорости. Хотя да, в Обероне с пулами будет тяжко в том плане, что для того, чтобы вероятность ошики (утечеки) придется городить системе каллбэков. Иначе никак.
-
arr := NEW(len);
Какой именно тут NEW будет вызван будет зависеть от типа arr. Вот в этом снос мозга. Это сильно не обычная функция получается. Очень не обычная. NEW как proper procedure конечно тоже не обычная. Который NEW будет вызван там зависит от типа аргумента. Однако такая перегрузка процедур-функций более привычна, ибо она встречается повсеместно в других языках.
Это снос мозга сишника -в си с указателями можно сделать многое... в обероне только присваивать и сравнивать ("равно" и "неравно") с NIL и значением переменной-указателя ТАКОГО же типа... впрочем я повторяюсь... :)
Про ограничение операций над указателями тут вообще не в тему. Замени arr на любой другой тип (INTEGER, BOOL, RECORD какой-нибудь (не ссылка на него)) – ничего не изменится. Крышесном останется.
Там может быть только ССЫЛКА на конкретный экземпляр RECORD либо NIL... произвольный адрес присвоить указателю нельзя ... или можно ?
-
Там может быть только ССЫЛКА на конкретный экземпляр RECORD либо NIL... произвольный адрес присвоить указателю нельзя ... или можно ?
Можно через SYSTEM. Но то, какие именно значения может принимать ссылка к крышесносу, мною обозначенному, никакого отношения не имеет.
-
Там может быть только ССЫЛКА на конкретный экземпляр RECORD либо NIL... произвольный адрес присвоить указателю нельзя ... или можно ?
Можно через SYSTEM. Но то, какие именно значения может принимать ссылка к крышесносу, мною обозначенному, никакого отношения не имеет.
Систем это систем.... Но все равно не понимаю чем хуже P:=NEW() в сравнении с NEW(P), хотя возможно это потому, что привык шлепать фабричные функции для составных сущностей.... Ну и ладно ... :)
-
Выложил описание компилятора: http://exaprog.com/userguide.pdf (http://exaprog.com/userguide.pdf)
-
Выложил описание компилятора: http://exaprog.com/userguide.pdf (http://exaprog.com/userguide.pdf)
О! Оперативненько! Заценим.
-
2. Differences between Oberon-07M and Oberon-07
...
2) One dimensional arrays are allowed.
По моему, одномерные массивы в Обероне-07 и так были (как и двух, и трех и так далее мерные). Небыло массивов неизвестной на этапе компиляции длины.
Ну и неплохо бы описать что будет при делении на нуль (целочисленно, точкоплавающе), как работать с +inf, -inf, nan значениями для IEEE real'ов. Что будет при выходе за пределы массива. Что будет при арифметическом переполнении (для всех типов).
-
2. Differences between Oberon-07M and Oberon-07
...
2) One dimensional arrays are allowed.
По моему, одномерные массивы в Обероне-07 и так были (как и двух, и трех и так далее мерные). Небыло массивов неизвестной на этапе компиляции длины.
Ну и неплохо бы описать что будет при делении на нуль (целочисленно, точкоплавающе), как работать с +inf, -inf, nan значениями для IEEE real'ов. Что будет при выходе за границы массива. Что будет при арифметическом переполнении (для всех типов).
-
Да, там в предложении одно слово пропущено. Должно было быть One dimensional dynamic arrays allowed. Сейчас поправлю.
-
Еще одним аргументом в пользу динамических массивов было то, что некоторые WinApi функции требуют передачи им указателя на массив, размер которого в общем случае не известен.
А вот это уже да, аргумент. Можно пример такой WinAPI функции? А то на вскидку ничего не припоминается.
Да хоть CreateFile. Путь к файлу может быть больше MAX_PATH. Или там какой-нибудь RegQueryValue может возвращать при "нехватке" буфера размер, который нужен (распространенная практика). Другой вопрос, что можно это все в SYSTEM упрятать... Но в любом случае простой (пусть и SYSTEM) способ получить шмат памяти заданного размера - обязан быть.
P.S. Есть еще более тонкие извращения, не так распространенные в WinAPI, но нормальные для С-интерфейсов: последнее поле структуры - массив нулевой длины, который на самом деле ни разу не нулевой, а вы поняли...
-
P.S. Есть еще более тонкие извращения, не так распространенные в WinAPI, но нормальные для С-интерфейсов: последнее поле структуры - массив нулевой длины, который на самом деле ни разу не нулевой, а вы поняли...
А что мешает тут сделать также? Я ж DIzer'у тут уже все глаза замозолил этим ARRAY 0 OF CHAR :-)
-
Документ обновил.
-
P.S. Есть еще более тонкие извращения, не так распространенные в WinAPI, но нормальные для С-интерфейсов: последнее поле структуры - массив нулевой длины, который на самом деле ни разу не нулевой, а вы поняли...
А что мешает тут сделать также? Я ж DIzer'у тут уже все глаза замозолил этим ARRAY 0 OF CHAR :-)
Не, ARRAY 0 OF CHAR - фигово. Потому что это нифига не CHAR и нифига не ARRAY, а "шмат памяти". Лучше POINTER TO [MEMORY] или еще как, чтобы сразу было видно, что язык здесь кончился и пошел SYSTEM.
-
Не, ARRAY 0 OF CHAR - фигово. Потому что это нифига не CHAR и нифига не ARRAY, а "шмат памяти". Лучше POINTER TO [MEMORY] или еще как, чтобы сразу было видно, что язык здесь кончился и пошел SYSTEM.
Чего это? Вполне себе array, просто неизвестного размера (на этапе компиляции). Ты же знаешь зачем это в сях делают? Чтобы структура могла прямо в себе содержать массив любого размера обычно. Голова его сидит в конце, и все что до конца структуры (структура получается переменного размера), то его. И обычно там таки осмысленный тип этого самого массива. То есть это таки реально массив неизвестного на этапе компиляции размера, вполне конкретного типа массив. Это не тупо шмат памяти.
-
Не, ARRAY 0 OF CHAR - фигово. Потому что это нифига не CHAR и нифига не ARRAY, а "шмат памяти". Лучше POINTER TO [MEMORY] или еще как, чтобы сразу было видно, что язык здесь кончился и пошел SYSTEM.
Чего это? Вполне себе array, просто неизвестного размера (на этапе компиляции). Ты же знаешь зачем это в сях делают? Чтобы структура могла прямо в себе содержать массив любого размера обычно. Голова его сидит в конце, и все что до конца структуры (структура получается переменного размера), то его. И обычно там таки осмысленный тип этого самого массива. То есть это таки реально массив неизвестного на этапе компиляции размера, вполне конкретного типа массив. Это не тупо шмат памяти.
ИМХО, надо определиться, чего мы хотим от такого описания. Если мы хотим просто поддержки сишных интерфейсов, то POINTER TO - вполне достаточное решение. Особенно если расчитывать на полуавтоматический биндинг. Если мы хотим сами создавать такие извращенные интерфейсы, то да, там можно много чего еще нафантазировать: например мембер структуры, который задает этот размер и т.д. (см. COM'ский IDL).
-
Ой блин. Не, нафиг. Эдак монстро неправильное получится. Я хочу монстро правильное. Хочу писать модули расширения для языка/компилятора писать не правя сам компилятор, о чем я уже писал кстати. Вот там то можно будет в тех самых редких случаях когда оно нужно, воткнуть любое извращение. И будет сразу видно что это именно что извращение и сразу можно будет посмотреть как оно реализовано.
-
А что мешает тут сделать также? Я ж DIzer'у тут уже все глаза замозолил этим ARRAY 0 OF CHAR :-)
Это точно.. но зачем - толком обьяснить не получилось... так что нафиг...- все извращения в SYSTEM (для извращенцев) :) а еще лучше не оберон 07 нужно править, а делать кастратный СИ и мозги не компостировать....
-
Пара багрепортов от меня:
1) Компилятор не ругается на использование неинициализированных переменных.
Это затрудняет отладку программ.
2) Виртовский вариант цикла Дейкстры реализован как-то неправильно. Вот стандартный пример его использования:
MODULE TestGCD;
IMPORT c := Console;
PROCEDURE GCD(x, y: INTEGER) : INTEGER;
BEGIN
WHILE x > y DO x := x - y
ELSIF x < y DO y := y - x
END;
ASSERT(x = y);
RETURN x
END GCD;
BEGIN
c.Int(GCD(255, 150));
c.Ln;
END TestGCD.Программа падает на ассерте, в логе пишется:
TestGCD.GCD
x INTEGER 105
y INTEGER 45хотя при данных аргументах (255 и 150) обе переменные должны быть равны 15, и сам цикл должен завершаться, когда x = y.
Сишный аналог этой процедуры работает правильно:
#define WHILE for(;;) if (
#define DO ) {
#define ELSIF ; } else if (
#define WEND ; } else break
#define ASSERT(p) if (!(p)) { printf("Oops in %s at line %d", __FILE__, __LINE__); exit(1); }
int gcd(int x, int y)
{
WHILE x > y DO x = x - y
ELSIF x < y DO y = y - x
WEND;
ASSERT(x == y);
return x;
}
3) Вот такой вариант тоже падает на ассерте:
PROCEDURE GCDrec(x, y: INTEGER) : INTEGER;
VAR
result : INTEGER;
BEGIN
IF x > y THEN result := GCDrec(x-y, y )
ELSIF x < y THEN result := GCDrec( x, y-x)
ELSE result := x
END;
ASSERT(x = y);
RETURN result
END GCDrec;Такое впечатление, что что-то не то с операциями сравнения...
-
WHILE x > y DO x := x - y
ELSIF x < y DO y := y - x
END;
...
Такое впечатление, что что-то не то с операциями сравнения...
Похоже, что после выполнения "DO ..." в ветке "ELSIF..." управление передаётся не на начало оператора, а на его конец.
-
Вообще как-то странно компилирует этот компилятор. Вот, декомпилировал эту функцию:
PROCEDURE GCD(x, y: INTEGER) : INTEGER;
BEGIN
WHILE x > y DO x := x - y
ELSIF x < y DO y := y - x
END;
RETURN x
END GCD;Получил страшный ужас:
int __cdecl sub_407971(int a1, int a2, int a3)
{
signed int v0; // ecx@2
signed int v1; // ecx@6
int r; // [sp+0h] [bp+0h]@1
dword_409FFC = (int)& r;
while ( 1 )
{
v0 = 1;
if ( a3 <= a2 )
v0 = 0;
if ( v0 != 1 )
break;
a3 -= a2;
}
while ( 1 )
{
v1 = 1;
if ( a3 >= a2 )
v1 = 0;
if ( v1 != 1 )
break;
a2 -= a3;
}
return a3;
}Во-первых, какой-то левый неиспользуемый параметр появился у функции.
Во-вторых, самое главное, цикл:
WHILE x > y DO x := x - y
ELSIF x < y DO y := y - x
END;скомпилировался в что-то типа этого:
WHILE x > y DO x := x - y END;
WHILE x < y DO y := y - x END;Но это же неверное представление цикла Дейкстры!
-
Компилятор TinyC, кстати, забавно оптимизировал эту функцию:
#define WHILE for(;;) if (
#define DO ) {
#define ELSIF ; } else if (
#define WEND ; } else break
int gcd(int x, int y)
{
WHILE x > y DO x = x - y
ELSIF x < y DO y = y - x
WEND;
return x;
}декомпиляция выдала такое:
int __cdecl sub_401070(int a1, int a2)
{
while ( 1 )
{
while ( a1 > a2 )
a1 -= a2;
if ( a1 >= a2 )
break;
a2 -= a1;
}
return a1;
}Вполне вменяемо. Хотя "if ( a1 >= a2 ) break;" немного смущает.
Вот так было бы лучше:
int gcd(int x, int y)
{
do
{
while (x > y) x -= y;
while (x < y) y -= x;
} while (x != y);
return x;
}
-
Новые компиляторы по-хорошему нужно прогонять на множестве тестов, специально разработанных для проверки компилятора на соответствие спецификации.
Мне неизвестно есть ли такой набор тестов для Оберон-07. Хорошо бы найти. ;)
Разработка такого набора тестов - сама по себе нетривиальная задача. Тесты должны обеспечивать полноту проверки (по возможности, конечно).
Rifat, интересно как Вы решали эту проблему? Или тестирование Вашего компилятора пока ещё не проводилось?
-
Новые компиляторы по-хорошему нужно прогонять на множестве тестов, специально разработанных для проверки компилятора на соответствие спецификации.
Тестирование доказывает лишь наличие ошибок.
Во французском университете INRIA разработали верифицированный компилятор подмножества Си для PowerPC (http://compcert.inria.fr/) -- это куда надёжнее, чем просто тестирование на наборе тестов...
-
Проблему с циклом Дейкстры решил. Выложил новую версию на сайт.
Насчет тестирования, в процессе работы, я создавал тесты для себя на которых тестировал. Согласен, чтобы было бы хорошо иметь набор эталонных тестов и прогонять на них. Может со временем такой набор тестов появится.
-
Тестирование доказывает лишь наличие ошибок.
Да, конечно. Успешное прохождение всех тестов не гарантирует отсутствие ошибок.
-
3) Вот такой вариант тоже падает на ассерте:
PROCEDURE GCDrec(x, y: INTEGER) : INTEGER;
VAR
result : INTEGER;
BEGIN
IF x > y THEN result := GCDrec(x-y, y )
ELSIF x < y THEN result := GCDrec( x, y-x)
ELSE result := x
END;
ASSERT(x = y);
RETURN result
END GCDrec;Такое впечатление, что что-то не то с операциями сравнения...
В этой процедуре ассерт в этом месте нельзя ставить, оказывается. Он падает на промежуточных рекурсивных вызовах, хотя в самом конце всё правильно срабатывает.
Так что минус один баг...
-
1) Компилятор не ругается на использование неинициализированных переменных.
Это затрудняет отладку программ.
Вообще-то это не является ошибкой с точки зрения компилятора. Согласен, что было бы хорошо выдавать warning, при этом. По сути, этим должен заниматься статический анализатор, который будет статически искать ошибки.
Для C++, существует статический анализатор Lint, который анализирует около 1000 разных ошибочных ситуаций и выдает предупреждения. Было бы хорошо, если кто-нибудь дал ссылку на книгу или сайт, где описывается как можно сделать статический анализатор. Насчет данного конкретного случая, можно просто решить, но затем может появиться другая ситуация, которую тоже надо будет отлавливать, поэтому я хочу решить эту проблему как можно в более общем случае, как это сделано в программе Lint.
-
В clang (фронтенде для c/c++/objc llvm) тоже есть статический анализатор кода. Все доступно в исходниках под MIT/BSD лицензией. Можно посмотреть.
-
Исходники разбирать сложнее, чем прочитать толковую книгу или статью, где это описано.
-
Да, кстати, clang умеет дампить полный AST в виде xml, что дюже удобно для написания тулзей для анализа кода. Если бы новый Оберон-07М компилятор умел бы нечто подобное, было бы очень здорово, ну и кто-нибудь мог бы написать тулзу (или несколько тулзов) для анализа кода и выявления ошибок потенциальных.
-
Сложно будет сделать этот AST стандартизированным, чтобы он удовлетворял потребностям разных людей. С другой стороны, многим ли людям он сейчас нужен, возможно, что если у человека возникнет такая потребность, он достаточно быстро сам это реализует.
-
Сложно будет сделать этот AST стандартизированным, чтобы он удовлетворял потребностям разных людей. С другой стороны, многим ли людям он сейчас нужен, возможно, что если у человека возникнет такая потребность, он достаточно быстро сам это реализует.
Не понял. Дерево разбора однозначно определяется грамматикой языка и даденым исходником. Я слабо себе представляю как можно выдать в виде xml AST не удобный для кого-нибудь. Посмотри как сдампленый AST выглядит у clang'a.
-
Одну и ту же конструкцию можно по-разному преобразовать в дерево и соответственно получить разные дампы.
В любом случае, генерация всяких дампов усложнит компилятор, что не желательно.
-
Одну и ту же конструкцию можно по-разному преобразовать в дерево и соответственно получить разные дампы.
Гм. А можно пример?
В любом случае, генерация всяких дампов усложнит компилятор, что не желательно.
Насколько я знаю, эти дампы делают в первую очередь для того, чтобы иметь больше возможностей отладки компилятора. Чтобы видеть что у него унутре происходит на каждом из этапов. Скажем в gcc подобный дамп именно для этих целей используется в первую очередь.
-
И всё-таки хотелось бы задать парочку "интимных" вопросов :)
Например, какое внутреннее промежуточное представление Вы используете? Или Вы транслируете дерево разбора напрямую сразу в машинный код? Вообще, есть какие-нибудь особенности в реализации компилятора, или всё по науке? :)
Да, и про оптимизацию пару слов, пожалуйста.
-
Маленькое замечание по "Hello, World!".
Необходимость в импорте Memory не очевидна (формально нигде не используется).
Понятно, что хотелось продемонстрировать работу с динамическими массивами, но всё же...
(Аналогичная картина с модулем Kernel в Блэкбокс, но там хотя бы есть оговорка в доках).
-
Маленькое замечание по "Hello, World!".
Необходимость в импорте Memory не очевидна (формально нигде не используется).
Понятно, что хотелось продемонстрировать работу с динамическими массивами, но всё же...
(Аналогичная картина с модулем Kernel в Блэкбокс, но там хотя бы есть оговорка в доках).
Думаю когда ББ был на том же этапе развития, что и данный компилятор, в его доках тоже ничего не было :-)
-
Например, какое внутреннее промежуточное представление Вы используете? Или Вы транслируете дерево разбора напрямую сразу в машинный код? Вообще, есть какие-нибудь особенности в реализации компилятора, или всё по науке? :)
В принципе, в духе оберонов компилировать всё сразу в машкод, ибо однопроходный компилятор. Так завещал Вирт...
-
На самом деле Вирт завещал компилировать в два прохода. Судя по его книжке по конструированию компиляторов. Разделять фронтенд и бэкенд. И это правильно.
-
Как-то читал, как японцы сделали персоналку (80-е годы вроде), у которой входным языком был паскаль, а не бейсик там или ассемблер.
Однопроходный компилятор компилил программу по мере её ввода строка за строкой ))
-
Как-то читал, как японцы сделали персоналку (80-е годы вроде), у которой входным языком был паскаль, а не бейсик там или ассемблер.
Однопроходный компилятор компилил программу по мере её ввода строка за строкой ))
Дык BeOS же изначально была написана под Hobbit (http://en.wikipedia.org/wiki/AT%26T_Hobbit) который по сути и есть Си-машина. И это не япония, это вполне себе США.
-
Про внутреннее представление. Сначала строится дерево разбора, если компляция прошла успешно, то по дереву разбора генерируется код.
Про оптимизацию. Фактически оптимизации нет, код генерируется наиболее прямолинейным способом. В дальнейшем, возможно, будут некоторые оптимизации.
Про пример. Да было желание продемонстрировать работу с динамическими массивами. Если динамическая память не используется, то Memory можно не компилировать и удалить его из prj файла, чтобы он не включался. Более того, можно не включать файл Kernel, но если произойдет прерывание работы программы, то никакой информации не будет. А модуль Kernel производит раскрутку стека и выводит информацию о процедурах, в которых произошла ошибка, в файл error.log.
-
На самом деле Вирт завещал компилировать в два прохода. Судя по его книжке по конструированию компиляторов. Разделять фронтенд и бэкенд. И это правильно.
Нет. Разделение на front-end и back-end не увеличивает число проходов. Под проходом понимается этап компиляции, на котором производится просмотр исходного текста от начала до конца.
-
Про внутреннее представление. Сначала строится дерево разбора, если компляция прошла успешно, то по дереву разбора генерируется код.
Про оптимизацию. Фактически оптимизации нет, код генерируется наиболее прямолинейным способом. В дальнейшем, возможно, будут некоторые оптимизации.
Понятно. Кстати, если планируется в дальнейшем вводить некоторые оптимизации, то может оказаться целесообразным ввести промежуточное представление, которое удобно для проведения этих оптимизаций. С оптимизациями главное не перемудрить. :)
-
Поясню на всякий случай – мы тут размер не знаем ни на этапе компиляции, ни на этапе исполнения. Если после вызова функции нам оно скажет что "нишмогла, не поместилась в буфер даденого размера", то стратегия проста – удваиваем размер буфера и пробуем снова. Для удваивания буфера, как я заметил выше, массивы с размером неизвестным на этапе компиляции не нужны.
В принципе я знаю, как решается эта проблема, но насколько это решение будет красивым. Например, в какую-нибудь внешнюю функцию нужно передать указатель на непрерывный кусок памяти, допустим от 256 байт до 1 Гб.
Тогда это можно сделать следующим способом:
TYPE
r1 = RECORD a1: ARRAY 256 OF CHAR END;
p1 = POINTER TO r1;
r2 = RECORD (r1) a2: ARRAY 256 OF CHAR END;
p2 = POINTER TO r2;
r3 = RECORD (r2) a3: ARRAY 512 OF CHAR END;
p3 = POINTER TO r3;
r4 = RECORD (r3) a4: ARRAY 1024 OF CHAR END;
p4 = POINTER TO r4;
r5 = RECORD (r4) a5: ARRAY 2048 OF CHAR END;
p5 = POINTER TO p5;
p6 = RECORD (p5) a6: ARRAY 4096 OF CHAR END;
p6 = POINTER TO r6;
r7 = RECORD (r6) a7: ARRAY 8192 OF CHAR END;
p7 = POINTER TO r7;
r8 = RECORD (r7) a8: ARRAY 16384 OF CHAR END;
p8 = POINTER TO r8;
r9 = RECORD (r8) a9: ARRAY 32768 OF CHAR END;
p9 = POINTER TO r9;
r10 = RECORD (r9) a10: ARRAY 65536 OF CHAR END;
p10 = POINTER TO r10;
r11 = RECORD (r10) a11: ARRAY 131072 OF CHAR END;
p11 = POINTER TO r11;
r12 = RECORD (r11) a12: ARRAY 262144 OF CHAR END;
p12 = POINTER TO r12;
r13 = RECORD (r12) a13: ARRAY 524288 OF CHAR END;
p13 = POINTER TO r13;
r14 = RECORD (r13) a14: ARRAY 1048576 OF CHAR END;
p14 = POINTER TO r14;
r15 = RECORD (r14) a15: ARRAY 2097152 OF CHAR END;
p15 = POINTER TO r15;
r16 = RECORD (r15) a16: ARRAY 4194304 OF CHAR END;
p16 = POINTER TO r16;
r17 = RECORD (r16) a17: ARRAY 8388608 OF CHAR END;
p17 = POINTER TO r17;
r18 = RECORD (r17) a18: ARRAY 16777216 OF CHAR END;
p18 = POINTER TO r18;
r19 = RECORD (r18) a19: ARRAY 33554432 OF CHAR END;
p19 = POINTER TO r19;
r20 = RECORD (r19) a20: ARRAY 67108864 OF CHAR END;
p20 = POINTER TO r20;
r21 = RECORD (r20) a21: ARRAY 134217728 OF CHAR END;
p21 = POINTER TO r21;
r22 = RECORD (r21) a22: ARRAY 268435456 OF CHAR END;
p22 = POINTER TO r22;
r23 = RECORD (r22) a23: ARRAY 536870912 OF CHAR END;
p23 = POINTER TO r23;
(* Должна вернуть указатель на данные *)
PROCEDURE GetAnswer(VAR p: p1);
VAR t1: p1; t2: p2; t3: p3; t4: p4; t5: p5; t6: p6; t7: p7; t8: p8; t9: p9;
t10: p10; t11: p11; t12: p12; t13: p13; t14: p14; t15: p15; t16: p16; t17: p17; t18: p18; t19: p19;
t20: p20; t21: p21; t22: p22; t23: p23; t24: p24;
size: INTEGER;
BEGIN
size := GetSize; (* Получаем размер данных *)
IF size <= 256 THEN NEW(t1); p := t1
ELSIF size <= 512 THEN NEW(t2); p := t2;
ELSIF size <= 1024 THEN NEW(t3); p := t3;
ELSIF size <= 2048 THEN NEW(t4); p := t4;
ELSIF size <= 4096 THEN NEW(t5); p := t5;
ELSIF size <= 8192 THEN NEW(t6); p := t6;
ELSIF size <= 16384 THEN NEW(t7); p := t7;
ELSIF size <= 32768 THEN NEW(t8); p := t8;
ELSIF size <= 65536 THEN NEW(t9); p := t9;
ELSIF size <= 131072 THEN NEW(t10); p := t10;
ELSIF size <= 262144 THEN NEW(t11); p := t11;
ELSIF size <= 524288 THEN NEW(t12); p := t12;
ELSIF size <= 1048576 THEN NEW(t13); p := t13;
ELSIF size <= 2097152 THEN NEW(t14); p := t14;
ELSIF size <= 4194304 THEN NEW(t15); p := t15;
ELSIF size <= 8388608 THEN NEW(t16); p := t16;
ELSIF size <= 16777216 THEN NEW(t17); p := t17;
ELSIF size <= 33554432 THEN NEW(t18); p := t18;
ELSIF size <= 67108864 THEN NEW(t19); p := t19;
ELSIF size <= 134217728 THEN NEW(t20); p := t20;
ELSIF size <= 268435456 THEN NEW(t21); p := t21;
ELSIF size <= 536870912 THEN NEW(t22); p := t22;
ELSE NEW(t23); p := t23;
END;
(* Передаем выделенную память во внешнюю систему *)
Answer(p^);
END GetAnswer;
(* Программу не компилировал, а просто написал, для примера *)
-
Поскольку подобные функции легко запихиваются в стандартную библиотеку, идущую, естественно, сразу с компилятором, которой потом все пользуются, это вполне красиво.
-
Но тут возможно есть засада: какая сигнатура у процедуры Answer?
-
Насчет сигнатуры не важно, допустим это адрес записанный в переменную типа INTEGER.
Еще одноа проблема в том, что к полученным данным невозможно обращаться по индексу, допустим мне нужен байт с индексом 1000000 из этого массива, как мне его найти? Или мне для начала надо будет все эти данные сначала перегнать в какую-то коллекцию, типа VList?
-
Насчет сигнатуры не важно, допустим это адрес записанный в переменную типа INTEGER.
Эмм. Тогда с этим шматом памяти придется работать исключительно через SYSTEM. Что не удобно, и если уж сразу работать с SYSTEM, что мешает без этих массивов просто сразу напрямую у системы просить выделить памяти шмат и указатель на него? Тот же INTEGER и получится, без посредников.
Еще одноа проблема в том, что к полученным данным невозможно обращаться по индексу, допустим мне нужен байт с индексом 1000000 из этого массива, как мне его найти? Или мне для начала надо будет все эти данные сначала перегнать в какую-то коллекцию, типа VList?
Почему не возможно? Смещение + Get. Вот и все. Проблема с типами – мы создали массив вполне кошерный, конкретного типа (размера и типа элементов), но тот кто просил у нас массив не знает какого типа массив у нас получился, а указателя на массив "вообще" в обероне-07, сколь я понимаю, не бывает. Следовательно мы можем возвренуть туда только просто адрес первой ячейки. И дальше с ним обращаться соответственно (ну можно конечно это дело инкапсулировать в какой-то opaque тип данных с методами, что будет закат в ручную).
Поэтому то и я предлагал, возвращать подобное с типом ARRAY 0 OF MyCoolType, соответственно 0 это синоним any или unknown. Это позволяет делать массивы размера неизвестного на этапе компиляции без изменения языка. Ну и вышеописанная проблема отменяется.
-
Обсуждение пошло немного не в то русло. Попробую еще раз разъяснить что я хотел сказать.
В Обероне-07 Вирт убрал динамические массивы, есть только статические массивы и указатели на записи. Причины по которым убрали динамические массивы мне частично понятны, одна из причин в том, что компилятор становится проще без них. Но нет четкой альтернативы что использовать вместо динамических массивов, там где они раньше использовались, по крайней мере я о них не очень много знаю.
Недавно, разговаривал с одним моим другом, и я у него спросил, нужны ли динамические массивы в Обероне, его ответ меня несколько удивил, он сказал, он считает что они не нужны, что должен быть набор различных коллекций, как в Яве, типа хэш массив, еще какой-нибудь массив и т.д., а как они устроены внутри нас это не должно волновать. Допустим, мы решили идти по этому пути, реализовали коллекцию массив, которая внутри себя представляет какой-нибудь VList. Но при этом, у нас будет много избыточной вычислительной работы, которая будет скрыта внутри этого контейнера.
Так вот меня интересует мнение общественности, как они считают, динамический массив должен быть отнесен к разряду родных для языка или же статических массивов и указателей на записи вполне хватает для большинства применений, а в некоторых случаях можно просто запросить блок памяти у модуля SYSTEM и вручную с ним работать, но при этом естественно не будет контроля границ, а при работе с динамическим массивом будет.
-
набор различных коллекций, как в Яве, типа хэш массив, еще какой-нибудь массив и т.д., а как они устроены внутри нас это не должно волновать. Допустим, мы решили идти по этому пути, реализовали коллекцию массив, которая внутри себя представляет какой-нибудь VList. Но при этом, у нас будет много избыточной вычислительной работы, которая будет скрыта внутри этого контейнера.
Товарищ лукавит: в яве есть массивы. Кроме того, в яве есть дженерики (которые конечно убоги по сравнению с плюсатыми шаблонами, но тем не менее). Массив, как встроенный тип данных, в Обероне, это тип с двумя параметрами – тип элемента, и число элементов. Либо одним параметром – тип элементов. Свои, не встроенные типы данных мы не можем сделать параметризуемыми. Поэтому, очевидно, мы воссоздать на уровне библиотеки массив (и любую другую коллекцию) просто не сможем. Получится только ущербное поделие, оно будет либо недостаточно гибко, либо небезопасно.
Тип пораметризуемый одним аргументом получается посредством свертки типа с двумя аргумантами по одному из них. Что я и предлагаю сделать. Для этого в компиляторе что-либо менять не нужно.
В Обероне-07 ЕСТЬ массивы длины неизвестной на момент компиляции. Система типов его существованию таких массивов никак не припятствует, достаточно свернуть ARRAY x OF y по первому аргументу, причем так, чтобы первый аргумент был не валиден для непосредственного обычного применения этого самого ARRAY x OF y (то есть чтобы его можно было создать только через функцию-процедуру NEW, но нельзя было создать его экзепляр просто так). Поэтому я и предлагаю использовать x=0.
Так вот меня интересует мнение общественности, как они считают, динамический массив должен быть отнесен к разряду родных для языка или же статических массивов и указателей на записи вполне хватает для большинства применений, а в некоторых случаях можно просто запросить блок памяти у модуля SYSTEM и вручную с ним работать, но при этом естественно не будет контроля границ, а при работе с динамическим массивом будет.
А почему это не будет? Работа с этим куском памяти любого размера может быть инкапсулирована в соответствующий модуль с соответствующим opaque типом данных. И все. И все там будет, и проверка границ, и что угодно еще. Быстродействие будет практически такое же, а при оптимизирующем компиляторе в точности такое же как и при встроенных массивах в язык.
-
В Обероне-07 ЕСТЬ массивы длины неизвестной на момент компиляции. Система типов его существованию таких массивов никак не припятствует, достаточно свернуть ARRAY x OF y по первому аргументу, причем так, чтобы первый аргумент был не валиден для непосредственного обычного применения этого самого ARRAY x OF y (то есть чтобы его можно было создать только через функцию-процедуру NEW, но нельзя было создать его экзепляр просто так). Поэтому я и предлагаю использовать x=0.
Думаю, что только вы так считаете, что в Oberon-07 есть массивы неизвестной длины. Если использовать 0 для обозначения массивов неизвестной длины, то будут появляться странности, например:
rec1 = RECORD a: ARRAY 2 OF INTEGER END; размер rec1 = 8 байт
rec2 = RECORD a: ARRAY 1 OF INTEGER END; размер rec2 = 4 байта
rec3 = RECORD a: ARRAY 0 OF INTEGER END; размер rec3 = 8 байт.
-
Про динамические массивы: http://patrasyen.livejournal.com/10928.html (http://patrasyen.livejournal.com/10928.html)
-
.... Поэтому я и предлагаю использовать x=0.
Хак ? Серьезно (предлагаете)? или стеб...
-
Думаю, что только вы так считаете, что в Oberon-07 есть массивы неизвестной длины. Если использовать 0 для обозначения массивов неизвестной длины, то будут появляться странности, например:
rec1 = RECORD a: ARRAY 2 OF INTEGER END; размер rec1 = 8 байт
rec2 = RECORD a: ARRAY 1 OF INTEGER END; размер rec2 = 4 байта
rec3 = RECORD a: ARRAY 0 OF INTEGER END; размер rec3 = 8 байт.
А откуда эти странности берутся? И где это проверялось? Просто по спеке на язык, никаких странностей быть не должно.
Гм. А что будет если:
rec3 = RECORD a: ARRAY -1 OF INTEGER END;
:-)
-
.... Поэтому я и предлагаю использовать x=0.
Хак ? Серьезно (предлагаете)? или стеб...
Я серьезно предлагаю сделать вначале хороший компилятор именно Оберона-07, использовть его, а потом, на базе уже этого опыта использования, думать в какую сторону пилить язык.
Поддержка на уровне компилятора динамических массивов не нужна, таким образом это никак не усложняет язык и компилятор. Единственное уточнение: при попытке создать нечто вроде такого:
a : ARRAY 0 OF SomeType;
должена быть ошибка компиляции. Естественно вот такая конструкция полностью валидна:
p : POINTER TO ARRAY 0 OF SomeType;
Создание этого в хипе экземпляра массива ARRAY 0 OF SomeType легко делается на уровне библиотеки, если вдруг кому-то понадобится. Вот использование то и покажет насколько оно нужно именно в языке.
Эдакое ленивое добавление фич в язык :-)
-
ARRAY 0 OF SomeType;
Если у нас ARRAY 1 OF SomeType, то компилятор должен разрешать обращение только к нулевому элементу массива arr[0].
А если ARRAY 0 OF SomeType, то ни к какому. И хотя вы выделите в библиотеке память для этого массива, обратиться к нему все равно нельзя будет.
-
ARRAY 0 OF SomeType;
Если у нас ARRAY 1 OF SomeType, то компилятор должен разрешать обращение только к нулевому элементу массива arr[0].
А если ARRAY 0 OF SomeType, то ни к какому. И хотя вы выделите в библиотеке память для этого массива, обратиться к нему все равно нельзя будет.
Где это сказано в спеке на язык?
Кроме того, компилятор не имеет возможности контролировать доступ к элементам массива в общем случае.
-
Если добавить динамические массивы, то в моем понимании будет бОльшая симметрия:
1) Есть обычные записи и обычные массивы
2) Есть указатели на записи и указатели на фиксированные массивы
3) Указатель на запись может указывать на запись расширенного типа и указатель на массив может указывать на массивы разных размеров. :)
-
Если добавить динамические массивы, то в моем понимании будет бОльшая симметрия:
1) Есть обычные записи и обычные массивы
2) Есть указатели на записи и указатели на фиксированные массивы
3) Указатель на запись может указывать на запись расширенного типа и указатель на массив может указывать на массивы разных размеров. :)
Стоп. В отличае от КП в Обероне нет AnyRec'a, то есть нет универсального указателя на запись, на сколько я помню. То же и с массивами. Так что аналогии не получается.
-
А при чем здесь AnyRec, я его не упоминал?
-
Вообще, такими темпами мы сейчас тут систему типов Ады изобретем :-) Поэтому, прежде чем изобретать, я таки и предлагаю попробовать Оберон-07 как он есть. И да, преобразование куска памяти к
ARRAY 0 OF SomeType это не безопасная операция, и без SYSTEM'а тут никак. Но этот SYSTEM будет сидеть в либе, а не в прикладном коде. И да, такие геморрои заставят использовать динамические массивы только тогда, когда это реально необходимо, а не когда просто лень подумать и решить сколько памяти надо.
Я думаю что это хороший, годный эксперимент.
Между прочим, в соседнем топике как раз задачка есть, на которой это дело можно было бы обкатать :-)
-
Я уже писал, что те кто не хочет чтобы в компиляторе были динамические массивы, могут просто их не использовать и считать что их просто нет. И использовать только те средства, которые были в описании языка Oberon-07.
-
Я уже писал, что те кто не хочет чтобы в компиляторе были динамические массивы, могут просто их не использовать и считать что их просто нет. И использовать только те средства, которые были в описании языка Oberon-07.
C тем же успехом можно сказать, что в С++ нет адресной арифметики, нет множественного наследования, исключений и многого иного, что мешает иногда жить.
-
Впрочем, наличие этой фичи аукнется потом, когда и если народ начнет активно использовать язык (не компилятор, а именно язык).
-
Я уже писал, что те кто не хочет чтобы в компиляторе были динамические массивы, могут просто их не использовать и считать что их просто нет. И использовать только те средства, которые были в описании языка Oberon-07.
C тем же успехом можно сказать, что в С++ нет адресной арифметики, нет множественного наследования, исключений и многого иного, что мешает иногда жить.
Читал какую-то статью, где рассказывалось о впечатлениях одного человека, когда он в каком-то году посетил программистский отдел Дойче банка в Германии. Он рассказывал, что они программировали на С++, но у них были такие строгие правила, что можно использовать и что нет, что их код на С++ был похож на код на Pascal-е.
Я сам работал в одной фирме, где программировали на C++, для нас там не существовал STL, было запрещено им пользоваться.
А вообще я думаю, что это не настолько большая проблема, если язык будет содержать одну дополнительную фичу. Сам Вирт всегда создавал свои языки под задачу.
-
Читал какую-то статью, где рассказывалось о впечатлениях одного человека, когда он в каком-то году посетил программистский отдел Дойче банка в Германии. Он рассказывал, что они программировали на С++, но у них были такие строгие правила, что можно использовать и что нет, что их код на С++ был похож на код на Pascal-е.
Это как раз нормально (если задача не подразумевает использования низкоуровневых моделей (и связанных с ними конструкций) - их незачем использовать)... просто Алексей одержим идеей сделать из 07 минималистичный системный язык начального уровня... правильно? мне лично нравится диаметрально противоположная точка зрения....Вирт я так понял хотел сделать и то и другое... результат налицо...
-
Рифат, у Вирта в "16 страницах" описаны предопределённые процедуры INC и DEC, однако Ваш компилятор утверждает, что эти функции не определены.
Как так? Ошибка в компиляторе?
MODULE TestIncDec;
IMPORT c := Console;
VAR
x : INTEGER;
BEGIN
x := 1; c.Int(x); c.Ln;
INC(x); c.Int(x); c.Ln;
INC(x, 10); c.Int(x); c.Ln;
DEC(x); c.Int(x); c.Ln;
DEC(x, 10); c.Int(x); c.Ln;
END TestIncDec.Компилятор ругается на каждую строку, где указаны INC или DEC...
-
Как так? Ошибка в компиляторе?
В руководстве пользователя у Rifat'а приводится список реализованных предопределённых процедур и функций. INC и DEC среди них нет. Однако, в перечне различий между 07М и 07 это не отражено.
-
INC и DEC пока не реализованы, согласен, что они нужны, в ближайшее время они будут реализованы.
-
Таки мое мнение, что по сути в языке они не нужны, но коль уж они описаны, то надо сделать. Ибо совместимость.
-
Каковы новости проекта?
-
Новостей особых нет. Недавно узнал, что Вирт выпустил новый документ с новой ревизией языка Оберон. Думаю, нужно внести изменения в компилятор. Но пока напряженка со временем.
-
Новостей особых нет. Недавно узнал, что Вирт выпустил новый документ с новой ревизией языка Оберон. Думаю, нужно внести изменения в компилятор. Но пока напряженка со временем.
Ссылка есть?
-
Новостей особых нет. Недавно узнал, что Вирт выпустил новый документ с новой ревизией языка Оберон. Думаю, нужно внести изменения в компилятор. Но пока напряженка со временем.
Ссылка есть?
Видимо вот это:
Niklaus Wirth. The Programming Language Oberon
Revision 20.7.2011
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
-
Спасибо
-
Niklaus Wirth. The Programming Language Oberon
Revision 20.7.2011
http://www.inf.ethz.ch/personal/wirth/Articles/Oberon/Oberon07.Report.pdf
Документ снова обновился несколько дней назад:
Revision 22.9.2011
ссылка на скачивания всё та же.
-
2013-04-30
Build 10 of compiler and linker created.
Memory allocation is optimized.
http://exaprog.com/eng/news.html