OberonCore
https://forum.oberoncore.ru/

Кодогенератор, inline и переносимый формат
https://forum.oberoncore.ru/viewtopic.php?f=2&t=528		 Страница 2 из 4
Автор:  Иван Горячев [ Пятница, 22 Июнь, 2007 10:43 ]
Заголовок сообщения: 
PGR писал(а):
не делать же всё from scratch :)

А почему бы и нет? Это будет способствовать полному пониманию и дальнейшему развитию.
Автор:  Vlad [ Пятница, 22 Июнь, 2007 11:11 ]
Заголовок сообщения: 
Александр Ильин писал(а):
Еще можно сделать удаление "мертвого" кода хотя бы на уровне процедур. Если процедура не экспортирована и нигде в модуле не используется ее идентификатор, то не генерировать для нее код.


А как же рефлекшн, без которого оберон-системам никак?
Автор:  Vlad [ Пятница, 22 Июнь, 2007 11:16 ]
Заголовок сообщения: 
Сергей Губанов писал(а):
Вот тут про inline говорят, а мне вот интересно как господа предлагают узнавать stack trace - какая процедура какую вызвала, если все процедуры заинлайнены? И уж не поэтому ли ни в Java ни в .Net никакого инлайна и в помине нету и не предвидется?


Есть там инлайнинг, и, насколько я знаю, уже давно. Технических подробностей о восстанавлении корректного стэк трэйса я не знаю.
Автор:  Иван Горячев [ Пятница, 22 Июнь, 2007 11:18 ]
Заголовок сообщения: 
Vlad писал(а):
А как же рефлекшн, без которого оберон-системам никак?

А с помощью рефекшна в неэкспортированную процедуру попасть затруднительно. А уж в "мёртвую" - тем более.
Автор:  Vlad [ Пятница, 22 Июнь, 2007 11:32 ]
Заголовок сообщения: 
Ivor писал(а):
Vlad писал(а):
А как же рефлекшн, без которого оберон-системам никак?

А с помощью рефекшна в неэкспортированную процедуру попасть затруднительно. А уж в "мёртвую" - тем более.


Мне казалось, что Илья Ермаков как раз говорил о том, что в ББ можно легко добраться до неэкспортированныых типов через рефлекшн. Еще можно вспомнить о "библиотечной реализации механизма исключений с нулевым оверхедом", где "нулевость" подразумевает доступность всего через рефлекшн. Или вот предлагавшаяся реализация форматирования текста - тоже без 100% рефлекшна работать не будет.
Автор:  PGR [ Пятница, 22 Июнь, 2007 11:40 ]
Заголовок сообщения: 
Продолжение предложений :)
В модуле Math также убрать WAIT. А еще лучше такие функции, как SQRT, SIN, COS, LN, ... вообще перенести в компилятор.

P.S. А еще в Math такое понравилось :)
Код:
  (* sin, cos, tan argument reduction *)
  PROCEDURE Reduce;
  BEGIN
    FXAM; WAIT;
    IF ~(8 IN FSWs()) & (ABS(ST0()) > 1.0E18) THEN
      (* to be completed *)
      FSTPst0; FLD0
    END;
  END Reduce;
Автор:  Иван Горячев [ Пятница, 22 Июнь, 2007 12:18 ]
Заголовок сообщения: 
Vlad:
всё это так, но пытаться попасть в "мёртвую" процедуру через рефлекшн - это уже извращениями попахивает. Строго говоря, сообщение о языке ничего особенного про рефлекшн не говорит - всё отдаётся на откуп конкретной реализации системы. И если программист использует в программе хитрый доступ к "мёртвым" процедурам, а система эти процедуры порежет - это проблемы программиста.
Автор:  PGR [ Пятница, 22 Июнь, 2007 12:25 ]
Заголовок сообщения: 
Документацию кто-нибудь вообще читал?
Цитата:
Meta provides access to Component Pascal run-time type information. Meta is restricted to public information, i.e., it doesn't allow access to non-exported items of a module.
Автор:  Александр Ильин [ Пятница, 22 Июнь, 2007 12:48 ]
Заголовок сообщения: 
Я согласен с документацией и с Ivor: если процедура должна быть видна извне, для этого предназначен экспорт. Иначе, лезть куда-то через недокументированный Kernel в обход Meta, - это плохой стиль. Для особых нужд есть прозрачные механизмы непрямого экспорта (хуки и директории).

При желании поизвращаться всегда можно "мертвый" код "прибить гвоздями", например, к глобальным неэкспортированным процедурным переменным, чтобы код для них был сгенерирован и доступ через метаинформацию из Kernel - можно было получить. Я же предлагаю всего лишь выкидывать лишний код, который был случайно забыт программистом или оставлен в исходнике на всякий тестовый случай.
Автор:  Vlad [ Пятница, 22 Июнь, 2007 13:16 ]
Заголовок сообщения: 
Александр Ильин писал(а):
При желании поизвращаться всегда можно "мертвый" код "прибить гвоздями", например, к глобальным неэкспортированным процедурным переменным,


Это будет смотреться весьма странно. И будет работать до той поры, пока не захочется выкидывать код, который не используется или "прибит" к неиспользуемому коду. Короче, вариант с ограничением рефлекшна только экспортируемыми сущностями кажется наиболее разумным и непротиворечимым. Однако такой вариант не оставляет места для некоторых практически востребованных "маневров".
Автор:  Александр Ильин [ Пятница, 22 Июнь, 2007 13:35 ]
Заголовок сообщения: 
Vlad писал(а):
Это будет смотреться весьма странно. И будет работать до той поры, пока не захочется выкидывать код, который не используется или "прибит" к неиспользуемому коду. Короче, вариант с ограничением рефлекшна только экспортируемыми сущностями кажется наиболее разумным и непротиворечимым. Однако такой вариант не оставляет места для некоторых практически востребованных "маневров".

Нет, Vlad, я предлагаю довольно простой маневр: если процедура не имеет признака экспорта в объявлении, то она уже кандидат на выброс. Остается только отследить, не используется ли ее имя где-то в том же модуле за пределами неё самой (т.е. рекурсия не является способом использования). Если её имя нигде больше не упоминается, можно выкидывать. Критерий довольно четкий и однозначный. Думается, это должно быть несложно реализовать.
Если таким образом была выброшена хотя бы одна процедура, надо сделать еще один проход, чтобы выяснить, не найдется ли ещё "мертвых" душ, используемых только уже выброшенными. При необходимости повторить от одного до трех раз (константу подобрать эмпирически и не документировать).
Автор:  Илья Ермаков [ Пятница, 22 Июнь, 2007 14:03 ]
Заголовок сообщения: 
На самом деле, с дискуссией о рефлекшене всё просто - есть два разных понятия - "метаинформация" и "символьная информация", и ББ их четко разграничивает.

Метаинформация - на экспортированные сущности + на ВСЕ дескрипторы типы (это нужно сборщику мусора, + доступ к экспортированным полям неэкспортированного типа, допускаемый Meta, тоже имеет смысл).

Символьная информация (references, группа Ref-процедур ядра) - дополнительная информация о скрытых сущностях, локальных переменных и т.п. Используется отладчиком и т.п. Недокументированная опция компилятора позволяет ее не включать.
Автор:  Vlad [ Пятница, 22 Июнь, 2007 14:36 ]
Заголовок сообщения: 
Александр Ильин писал(а):
Нет, Vlad, я предлагаю довольно простой маневр: если процедура не имеет признака экспорта в объявлении


Под "маневрами" я подразумевал конкретную реализацию механизма исключений (использующую локальные процедуры) и реализацию форматирования текста (использующую доступ к локальным переменным).
Автор:  Сергей Оборотов [ Пятница, 22 Июнь, 2007 20:14 ]
Заголовок сообщения: 
Ivor писал(а):
GUEST писал(а):
Очевидно такая подстановка есть задача представления нескольких вариантов исходного текста, а не для работы компилятора.

По-моему - как раз работа компилятора.

Я считаю нет, поскольку имеет место быть не перевод одного фрагмента, а пояснение к нему.
Ivor писал(а):
Есть некоторые мыслишки... Приделать slim-binaries, при этом загрузчик должен предоставлять интерфейс для плагинов-оптимизаторов. Загрузчик линкуем в исполнимый файл, а модули оптимизаторов подключаем отдельно. Забавная схема получается - для увеличения скорости кода клиентам высылается дополнительный модуль оптимизатора...
Бесспорно, а главное уже опробовано.
Автор:  Сергей Оборотов [ Пятница, 22 Июнь, 2007 20:16 ]
Заголовок сообщения: 
PGR писал(а):
Ivor писал(а):
В смысле компилятор править. И кодогенерирующий загрузчик писать. А кому сейчас легко ;)

Почему править? Уже...
Цитата:
The Compiler is an important component of the Oberon system. Except for parts of the inner core, Oberon System 3 is implemented in the original Oberon language. The compiler supplied is an Oberon-2 compiler. Any Oberon-2 compiler is compatible in principle with System 3 and System 3 programs can be written and compiled with Oberon-2.The compiler can generate two types of object files: classical native object files containing target machine code or by default slim binaries. Slim binaries are a new form of object files that contain no object code at all, but a portable description of module's content that makes these files completely independent of the eventual target machine (platform independent). Object code generation is carried out on-the-fly by the module loader (depending on the underlying hardware) and takes no longer than loading traditional object files.

Только "by default" реально генерируется native...
В Oberon System 3 по умолчанию портируемый формат. Загрузчик его расположен в модуле Win32.Interchange.Mod
Автор:  PGR [ Пятница, 22 Июнь, 2007 20:59 ]
Заголовок сообщения: 
GUEST писал(а):
В Oberon System 3 по умолчанию портируемый формат. Загрузчик его расположен в модуле Win32.Interchange.Mod

У меня ETH Oberon for Windows. Цитата из документации, идущей с ним. Это Oberon System 3 ? Такого модуля здесь нет.
Автор:  PGR [ Пятница, 22 Июнь, 2007 22:56 ]
Заголовок сообщения: 
PGR писал(а):
Это Oberon System 3 ?

В readme.txt написано
Цитата:
As you may allready have noticed, that we use now the name "ETH Oberon" for "Oberon System 3".

Почему тогда нет модуля Win32.Interchange.Mod ?
Автор:  Иван Горячев [ Суббота, 23 Июнь, 2007 09:03 ]
Заголовок сообщения: 
Нашёл! На том же ftp берём старую версию, оно там лежит ftp://ftp.inf.ethz.ch/pub/software/Oberon/System3/Win95NT/Old/Src.exe
Автор:  batyrmastyr [ Суббота, 23 Июнь, 2007 18:11 ]
Заголовок сообщения: 
Александр Ильин писал(а):
Нет, Vlad, я предлагаю довольно простой маневр: если процедура не имеет признака экспорта в объявлении, то она уже кандидат на выброс. Остается только отследить, не используется ли ее имя где-то в том же модуле за пределами неё самой (т.е. рекурсия не является способом использования). Если её имя нигде больше не упоминается, можно выкидывать. Критерий довольно четкий и однозначный. Думается, это должно быть несложно реализовать.

То есть, как со сборкой мусора: оставляем все экспортируемые процедуры, и те неэкспортируемые, которые могут быть вызваны из них.
Автор:  PGR [ Суббота, 23 Июнь, 2007 19:35 ]
Заголовок сообщения: 
Ivor писал(а):
Нашёл! На том же ftp берём старую версию, оно там лежит ftp://ftp.inf.ethz.ch/pub/software/Oberon/System3/Win95NT/Old/Src.exe


Вот что они об этом пишут (http://www.oberon.ethz.ch/compiler/):
Цитата:
Note concerning Slim Binaries, often referred to as "OMI"

OMI is now history and not implemented in the current ETH Oberon system. This very interesting technology was not integrated into the new compiler because we did change the language many times and this required some deep changes to the compiler. The OMI implementation we had (and still have) was optimized for the OP2 parse tree to the extent that changing anything in the parse tree or symbol table would break or cripple it, and it should have been de-optimized first or even rewritten for the new parse tree. Anyway, this is still possible, and it would be interesting, to have somebody take over the OMI code and adapt it to the extended symbol table and parse tree used for Active Oberon.
Страница 2 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/