OberonCore • - Кодогенератор, inline и переносимый формат

Сообщения без ответов | Активные темы

Список форумов » BlackBox Component Builder » Системные вопросы

Часовой пояс: UTC + 3 часа

Кодогенератор, inline и переносимый формат

Страница 2 из 4

[ Сообщений: 80 ]

На страницу Пред. 1, 2, 3, 4 След.

Версия для печати

Пред. тема | След. тема

Автор

Сообщение

Иван Горячев

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 10:43

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток

PGR писал(а):

не делать же всё from scratch

А почему бы и нет? Это будет способствовать полному пониманию и дальнейшему развитию.

Вернуться к началу

Vlad

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 11:11

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857

Александр Ильин писал(а):

Еще можно сделать удаление "мертвого" кода хотя бы на уровне процедур. Если процедура не экспортирована и нигде в модуле не используется ее идентификатор, то не генерировать для нее код.

А как же рефлекшн, без которого оберон-системам никак?

Вернуться к началу

Vlad

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 11:16

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857

Сергей Губанов писал(а):

Вот тут про inline говорят, а мне вот интересно как господа предлагают узнавать stack trace - какая процедура какую вызвала, если все процедуры заинлайнены? И уж не поэтому ли ни в Java ни в .Net никакого инлайна и в помине нету и не предвидется?

Есть там инлайнинг, и, насколько я знаю, уже давно. Технических подробностей о восстанавлении корректного стэк трэйса я не знаю.

Вернуться к началу

Иван Горячев

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 11:18

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток

Vlad писал(а):

А как же рефлекшн, без которого оберон-системам никак?

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

Вернуться к началу

Vlad

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 11:32

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857

Ivor писал(а):

Vlad писал(а):

А как же рефлекшн, без которого оберон-системам никак?

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

Мне казалось, что Илья Ермаков как раз говорил о том, что в ББ можно легко добраться до неэкспортированныых типов через рефлекшн. Еще можно вспомнить о "библиотечной реализации механизма исключений с нулевым оверхедом", где "нулевость" подразумевает доступность всего через рефлекшн. Или вот предлагавшаяся реализация форматирования текста - тоже без 100% рефлекшна работать не будет.

Вернуться к началу

PGR

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 11:40

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье

Продолжение предложений

В модуле 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

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток

Vlad:
всё это так, но пытаться попасть в "мёртвую" процедуру через рефлекшн - это уже извращениями попахивает. Строго говоря, сообщение о языке ничего особенного про рефлекшн не говорит - всё отдаётся на откуп конкретной реализации системы. И если программист использует в программе хитрый доступ к "мёртвым" процедурам, а система эти процедуры порежет - это проблемы программиста.

Вернуться к началу

PGR

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 12:25

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье

Документацию кто-нибудь вообще читал?

Цитата:

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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2463
Откуда: Россия, Томск

Я согласен с документацией и с Ivor: если процедура должна быть видна извне, для этого предназначен экспорт. Иначе, лезть куда-то через недокументированный Kernel в обход Meta, - это плохой стиль. Для особых нужд есть прозрачные механизмы непрямого экспорта (хуки и директории).

При желании поизвращаться всегда можно "мертвый" код "прибить гвоздями", например, к глобальным неэкспортированным процедурным переменным, чтобы код для них был сгенерирован и доступ через метаинформацию из Kernel - можно было получить. Я же предлагаю всего лишь выкидывать лишний код, который был случайно забыт программистом или оставлен в исходнике на всякий тестовый случай.

Вернуться к началу

Vlad

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 13:16

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857

Александр Ильин писал(а):

При желании поизвращаться всегда можно "мертвый" код "прибить гвоздями", например, к глобальным неэкспортированным процедурным переменным,

Это будет смотреться весьма странно. И будет работать до той поры, пока не захочется выкидывать код, который не используется или "прибит" к неиспользуемому коду. Короче, вариант с ограничением рефлекшна только экспортируемыми сущностями кажется наиболее разумным и непротиворечимым. Однако такой вариант не оставляет места для некоторых практически востребованных "маневров".

Вернуться к началу

Александр Ильин

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 13:35

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2463
Откуда: Россия, Томск

Vlad писал(а):

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

Вернуться к началу

Илья Ермаков

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 14:03

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл

На самом деле, с дискуссией о рефлекшене всё просто - есть два разных понятия - "метаинформация" и "символьная информация", и ББ их четко разграничивает.

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

Символьная информация (references, группа Ref-процедур ядра) - дополнительная информация о скрытых сущностях, локальных переменных и т.п. Используется отладчиком и т.п. Недокументированная опция компилятора позволяет ее не включать.

Вернуться к началу

Vlad

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 14:36

Зарегистрирован: Суббота, 26 Ноябрь, 2005 18:38
Сообщения: 1857

Александр Ильин писал(а):

Нет, Vlad, я предлагаю довольно простой маневр: если процедура не имеет признака экспорта в объявлении

Под "маневрами" я подразумевал конкретную реализацию механизма исключений (использующую локальные процедуры) и реализацию форматирования текста (использующую доступ к локальным переменным).

Вернуться к началу

Сергей Оборотов

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 20:14

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1030

Ivor писал(а):

GUEST писал(а):

Очевидно такая подстановка есть задача представления нескольких вариантов исходного текста, а не для работы компилятора.

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

Я считаю нет, поскольку имеет место быть не перевод одного фрагмента, а пояснение к нему.

Ivor писал(а):

Есть некоторые мыслишки... Приделать slim-binaries, при этом загрузчик должен предоставлять интерфейс для плагинов-оптимизаторов. Загрузчик линкуем в исполнимый файл, а модули оптимизаторов подключаем отдельно. Забавная схема получается - для увеличения скорости кода клиентам высылается дополнительный модуль оптимизатора...

Бесспорно, а главное уже опробовано.

Вернуться к началу

Сергей Оборотов

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 20:16

Зарегистрирован: Вторник, 29 Ноябрь, 2005 21:41
Сообщения: 1030

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

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье

GUEST писал(а):

В Oberon System 3 по умолчанию портируемый формат. Загрузчик его расположен в модуле Win32.Interchange.Mod

У меня ETH Oberon for Windows. Цитата из документации, идущей с ним. Это Oberon System 3 ? Такого модуля здесь нет.

Вернуться к началу

PGR

Заголовок сообщения:

Добавлено: Пятница, 22 Июнь, 2007 22:56

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье

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

Зарегистрирован: Суббота, 26 Ноябрь, 2005 10:37
Сообщения: 875
Откуда: Россия, Владивосток

Нашёл! На том же ftp берём старую версию, оно там лежит ftp://ftp.inf.ethz.ch/pub/software/Oberon/System3/Win95NT/Old/Src.exe

Вернуться к началу

batyrmastyr

Заголовок сообщения:

Добавлено: Суббота, 23 Июнь, 2007 18:11

Зарегистрирован: Среда, 28 Февраль, 2007 00:08
Сообщения: 142
Откуда: Нижний Новгород

Александр Ильин писал(а):

То есть, как со сборкой мусора: оставляем все экспортируемые процедуры, и те неэкспортируемые, которые могут быть вызваны из них.

Вернуться к началу

PGR

Заголовок сообщения:

Добавлено: Суббота, 23 Июнь, 2007 19:35

Зарегистрирован: Понедельник, 29 Январь, 2007 19:00
Сообщения: 370
Откуда: Украина, Запорожье

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

[ Сообщений: 80 ]

На страницу Пред. 1, 2, 3, 4 След.

Список форумов » BlackBox Component Builder » Системные вопросы

Часовой пояс: UTC + 3 часа

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения