Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - akron1

Страницы: [1] 2 3 ... 6
1
Общий раздел / Re: OberonJS
« : Февраль 18, 2017, 09:10:20 pm »
Geniepro,
Правила O7 требуют, чтобы процедура-функция заканчивалась на "RETURN expression".
Можно так:
PROCEDURE Sin* (x: REAL): REAL;
BEGIN
  JS.do("return Math.sin(x)")
  RETURN 0.0
END Sin;

Из-за этой особенности мне тоже иногда приходится использовать фиктивный RETURN, который никогда не выполняется:
PROCEDURE [stdcall] sysfunc1*(arg1: INTEGER): INTEGER;
BEGIN
  sys.CODE("8B4508");           (* mov     eax, [ebp + 08h] *)
  sys.CODE("CD40");             (* int     40h              *)
  sys.CODE("C9");               (* leave                    *)
  sys.CODE("C20400");           (* ret     04h              *)
  RETURN 0
END sysfunc1;

2
Сборщика мусора ведь нет?
:)
С самого начала разработки компилятора, я решил максимально упростить задачу. Я не был уверен, что у меня на это хватит способностей. Поэтому, получилось то, что получилось. Однопоточный сборщик мусора не ахти какая сложная вещь, но он меня не интересует. Многопоточный, напротив слишком сложен, поэтому я от него отказался. Вообще, я решился опубликовать компилятор, только потому, что Rifat каким-то образом умудрился сделать кодогенерацию еще хуже. А раз так, думаю, то и я могу. Хотя сначала, делал только для себя и не собирался это никому показывать.

3
Да, компилятор переехал на KolibriOS. Игрушечная ОС, игрушечный ЯВУ, игрушечный компилятор ). К тому же, там нет никаких IDE/отладчиков для ЯВУ, и в таких условиях проявляются преимущества оберона -- неплохая приспособленность для разработки в блокноте ). Актуальная версия в SVN
http://websvn.kolibrios.org/listing.php?repname=Kolibri+OS&path=%2Fprograms%2Fdevelop%2Foberon07%2F. Возможность кросс-компиляции никуда не делась и компилятор можно собрать из-под любой из трех ОС под любую другую. Но библиотеки теперь только для Колибри, для Windows/Linux осталось только то, что нужно самому компилятору.

Для Linux, в модуле /lib/linux32/API.ob07 есть процедурные переменные для использования системных библиотек
  dlopen*   : PROCEDURE [cdecl] (filename, flag: INTEGER): INTEGER;
  dlsym*   : PROCEDURE [cdecl] (handle, symbol: INTEGER): INTEGER;
и там же можно увидеть, как они используются. Также, есть привязки к некоторым другим системным функциям.

Аналогично, для Windows, \lib\Windows32\API.ob07:
  GetProcAddress*: PROCEDURE [winapi] (hModule, name: INTEGER): INTEGER;
  LoadLibraryA*: PROCEDURE [winapi] (name: INTEGER): INTEGER;

В отличие от Windows и KolibriOS, я не использовал компилятор для практической разработки под Linux. Не знаю, какие там могут быть проблемы, кроме отсутствия библиотек.

Я прикрепил архив, добавил туда бинарники для Windows и Linux, а также файл test.ob07 -- пример консольного вывода для Linux.

4
Это связано с архитектурой x86. Там для сдвигов влево и вправо используются разные команды. При этом, величина сдвига помещается в регистр cl (8 бит), но процессор учитывает только младшие 5 бит. Т. е. величина сдвига всегда в диапазоне 0..31. Не знаю как в ARM, но в реализации Astrobe тоже есть LSR.

5
Давно уже можно генерить для Linux, в инструкции написано. Только без библиотек это неудобно. И зачем тестировать на производительность игрушечный компилятор?

6
Итак, я написал несколько десятков тысяч строк некачественного, но работающего кода на этом языке. Кратко расскажу об этом опыте.

Сначала, надо уяснить, что Oberon-07, это язык, предназначенный для быстрой реализации с минимальными затратами и сравнительно эффективного применения в случае простейшей реализации. В связи с этим, все разговоры об умных компиляторах, современных средствах отладки, шаблонах, замыканиях и т. д. лишены смысла. Многие недостатки языка либо упрощают реализацию, либо упрощают отладку в условиях, когда есть только голый компилятор без каких-либо инструментов.

Перечислю некоторые особенности языка/реализации, которые можно считать недостатками:

- ран-тайм проверки (индексы, указатели). Замедляют и так небыстрые программы. Но оказывают неоценимую помощь, позволяют быстро выявить такие ошибки, которые бывает очень трудно найти без пошагового отладчика и прочих средств. Вряд ли я хоть что-нибудь написал бы на O7 без них. Конечно, люди разные, есть и такие, которые могут кодировать сразу без ошибок на любом языке, но я к таким не отношусь.

- сильная типизация. Тоже отлавливает очень много ошибок. И да, упрощает реализацию ).

- единственный выход из процедуры, отсутствие прерываний циклов. Спорная фича. Затрудняет кодинг, увеличивает размер и снижает эффективность кода, немного упрощает отладку.

- обязательная квалификация идентификаторов. На первый взгляд, избыточно. Раздувает и без того не очень компактный оберон-код. Но вот, как-то мне надо было просмотреть одну программу на паскале, так я задолбался искать процедуры по всем модулям. Конечно, эту проблему легко решает IDE, но ведь я говорю о простейшей реализации...

Операторы:

- CASE. Вероятно, использование этого оператора для проверки типа указателя (как в поздних ревизиях) вполне оправдано. Для проверки целочисленных значений позволяет сделать более эффективный и компактный машкод, чем серия IF. Без ELSE практически бесполезен.

- FOR. Лучше, если бы переменная-счетчик создавалась при входе в цикл и уничтожалась при выходе.

- WHILE ... DO ... ELSIF ... DO. "Цикл Дийкстры" - почти бесполезен, хотя и не мешает. Одно из немногих применений:
PROCEDURE Scroll (value: INTEGER);
BEGIN
  value := 2 * value;
  WHILE value > 0 DO
    Down;
    DEC(value)
  ELSIF value < 0 DO
    Up;
    INC(value)
  END
END Scroll;
Конечно, здесь можно сделать по-другому, но мне показалось, что "цикл Дийкстры" подходит лучше.

Типы:

- SET. Применяется нечасто, но бывает полезен, когда надо упаковать несколько булевских значений в одну переменную, чтобы не раздувать список параметров.
- Беззнаковое целое. Я ни разу не пожалел о его отсутствии. Конечно, бывают случаи, когда этот тип был бы полезен, но для 32-битной реализации это бывает нечасто. Для 64-бит, ИМХО, вообще "не стОит выделки".
- ANYREC, ANYPTR. Лучше бы были.
- Динамические массивы. Без них плохо.
- POINTER TO. Здесь желательно ослабить типизацию, как это сделано в КП.
- Псевдонимы типов. Лучше бы были. В поздних ревизия они есть.

Встроенные процедуры:

- ORD(BOOLEAN): INTEGER. Используется довольно часто, странно, что в AO ее нет.
- BITS(INTEGER): SET. Такой процедуры в O7 нет. Пришлось добавить в дополнение к ORD(SET): INTEGER.
- LSR. Такой процедуры нет, но она однозначно нужна. Тоже добавил в дополнение к LSL.
- LENGTH(ARRAY OF CHAR): INTEGER. Используется часто, лучше, когда она встроена в язык. Тоже добавил.

7
Общий раздел / Re: Числа в Обероне
« : Ноябрь 26, 2014, 03:13:05 pm »
Нет, ошибаюсь, не определены только для отрицательного делителя.

8
Общий раздел / Re: Числа в Обероне
« : Ноябрь 26, 2014, 03:06:04 pm »
Исходя из этого, OberonJs на соответствует описанию языка Оберон?

Т.к. условие
( (-5) DIV 3 ) # ( -5 DIV 3 )не соблюдается.

В языке Оберон DIV и MOD вообще не определены для отрицательных операндов. Даже в Оберон-2. Только в КП такое определение есть.

9
Общий раздел / AyaCompiler - Oberon-07 for AMD-64
« : Сентябрь 06, 2014, 12:16:20 am »
Через форум (zx.oberon2.ru/forum/) Олега Чередниченко (Zorko), узнал о готовящемся компиляторе Oberon-07 для AMD-64 (Windows) https://github.com/congdm/AyaCompiler. Реализует одну из последних ревизий языка. В отличие от моего кривого поделия, написан аккуратно и понятно. При генерации кода вычисления выражений, использует модель регистрового стэка (благо регистров больше). Правда сборщик мусора в компиляторе, по крайней мере пока, не предусмотрен. Написан на КП (GPCP), похоже, что будет переведен на Oberon-07. В настоящее время, не реализованы FOR, CASE, вещественная арифметика.

10
Как вам должно быть известно, в обероне есть "стандартные" процедуры -- INC, LSL, LEN... Эти процедуры не имеют исходного кода и обрабатываются компилятором как обычные операторы и операции. Как правило такие процедуры не вызываются а подставляются. Для компилятора нет принципиальной разницы между "стандартными" и SYSTEM-процедурами. Если компилятор встречает идентификатор "стандартной" или SYSTEM-процедуры, то вызывается процедура StFunc или StProc модуля Compiler, где происходит разбор параметров и генерация машинного кода.
Что касается генерации машинного кода для ARM, то сейчас это бесперспективно. Дело в том, что модуль Compiler (синтаскический разбор операторов и выражений) и модуль DECL (синтаксический разбор объявлений) тесно связаны с модулем X86. По-хорошему, компилятор должен сначала генерировать промежуточный (машино-независимый код), а затем транслировать его в машинный. То есть, модули Compiler и DECL обращаются к модулю генерации промежуточного кода, а потом трансляцию промежуточного кода в машинный выполняет модуль X86 или ARM. А пока, увы... У меня не было цели сделать что-то хорошее, просто "лишь бы работало", поэтому получилось так...

11
Проще? ИМХО, трансляция в C проще трансляции в кроссплатформенный, но все же по сути асм.
Безопаснее? Errare humanum est, но ведь код на C в данном случае пишет не человек, главное, чтобы не было ошибок в трансляторе и C-компиляторе.
Сишные либы? А какие операторы (операции, встроенные процедуры) O7 транслируются с использованием стандартной библиотеки C? В репорте я нашел только NEW (DISPOSE) и м. б. COPY, SYSTEM.MOVE, но соответствующие функции C реализованы для всех платформ. Всё остальное либо имеет прямые аналоги в языке C, либо легко реализуется средствами языка в виде функций без привлечения какой-либо библиотеки.

12
А какие преимущества у кодогенерации в LLVM перед кодогенерацией в C?

13
Извините, Борис, но гитхабом пользоваться не умею и учиться не хочу, потому что мне это не нужно -- я не кодер и не собираюсь им быть.

14
Хм... Могу попробовать. Все равно заняться в плане кодирования нечем -- новый кодогенератор и сборщик мусора пока делать не хочу.
А пока, изменений немного: улучшена поддержка Kolibri (dll, библиотеки, улучшена работа с динамической памятью), несколько увеличена скорость компиляции и плотность кода и некоторые мелкие поправки.
https://sites.google.com/site/oberon07compiler/versii

15
У акроновского компилятора ещё и операция проверки типа отличается от описания последней ревизии оберона -- вторым параметром требует имя типа указателя на запись вместо имени типа записи...
Не совсем так. В моей реализации первый и второй параметры должны соответствовать. Если первый параметр -- запись, то требуется имя типа-записи. В репорте написано:

Цитировать
v IS T stands for "v is of type T" and is called a type test. It is applicable, if
1. T is an extension of the declared type T0 of v, and if
2. v is a variable parameter of record type or v is a pointer.

Из этого не ясно, является ли тип T записью или указателем. И должен ли он соответствовать типу v.

Страницы: [1] 2 3 ... 6