OberonCore https://forum.oberoncore.ru/ |
|
Кодогенератор, inline и переносимый формат https://forum.oberoncore.ru/viewtopic.php?f=2&t=528 |
Страница 1 из 4 |
Автор: | Сергей Оборотов [ Четверг, 21 Июнь, 2007 20:03 ] |
Заголовок сообщения: | |
Если у кого-то есть предложения как улучшить работу кодогенератора BlackBox-а просьба их высказать. Не вижу причин по которым от разумной оптимизации надо отказываться. |
Автор: | PGR [ Четверг, 21 Июнь, 2007 22:53 ] |
Заголовок сообщения: | |
GUEST писал(а): Если у кого-то есть предложения как улучшить работу кодогенератора BlackBox-а просьба их высказать. Не вижу причин по которым от разумной оптимизации надо отказываться.
Есть предложение делать inline-подстановку маленьких процедур в место вызова. Вопрос в том, кто реализовывать будет... |
Автор: | PGR [ Четверг, 21 Июнь, 2007 23:06 ] |
Заголовок сообщения: | |
А ещё не генерировать кучу инструкций FWAIT при вычислениях с плавающей точкой. |
Автор: | Иван Горячев [ Пятница, 22 Июнь, 2007 00:53 ] |
Заголовок сообщения: | |
GUEST писал(а): Если у кого-то есть предложения как улучшить работу кодогенератора BlackBox-а просьба их высказать. Не вижу причин по которым от разумной оптимизации надо отказываться.
Есть большое такое, конкретное предложение - сначала перевести BlackBox на slim-binaries, а уже потом заниматься кодогенерацией. |
Автор: | PGR [ Пятница, 22 Июнь, 2007 02:40 ] |
Заголовок сообщения: | |
PGR писал(а): А ещё не генерировать кучу инструкций FWAIT при вычислениях с плавающей точкой.
Решается без проблем: удалить вызовы DevCPE.GenByte(9BH) из процедуры DevCPL486.GenFStore. |
Автор: | PGR [ Пятница, 22 Июнь, 2007 04:21 ] |
Заголовок сообщения: | |
Ещё Постоянные загрузки управляющего слова FPU: Код: push 33Eh
fldcw word ptr [esp] pop ecx Устраняется удалением всех вызовов InitFpu в модуле DevCPC486. Также DevCPC486.InitFpu еще и дублируется в Kernel.InitFpu. Наверное, однократной инициализации при старте BlackBox будет достаточно... |
Автор: | Сергей Оборотов [ Пятница, 22 Июнь, 2007 05:24 ] |
Заголовок сообщения: | |
PGR писал(а): Есть предложение делать inline-подстановку маленьких процедур в место вызова. Очевидно такая подстановка есть задача представления нескольких вариантов исходного текста, а не для работы компилятора.PGR писал(а): Вопрос в том, кто реализовывать будет... Вначале надо определить что именно.
|
Автор: | Иван Горячев [ Пятница, 22 Июнь, 2007 06:53 ] |
Заголовок сообщения: | |
GUEST писал(а): Очевидно такая подстановка есть задача представления нескольких вариантов исходного текста, а не для работы компилятора. По-моему - как раз работа компилятора. А если перенести компиляцию в загрузчик - можно и межмодульный inline замутить, с сохранением возможности загрузки/выгрузки модулей. Цитата: Вначале надо определить что именно.
Есть некоторые мыслишки... Приделать slim-binaries, при этом загрузчик должен предоставлять интерфейс для плагинов-оптимизаторов. Загрузчик линкуем в исполнимый файл, а модули оптимизаторов подключаем отдельно. Забавная схема получается - для увеличения скорости кода клиентам высылается дополнительный модуль оптимизатора... |
Автор: | PGR [ Пятница, 22 Июнь, 2007 09:04 ] |
Заголовок сообщения: | |
Ivor писал(а): А если перенести компиляцию в загрузчик - можно и межмодульный inline замутить, с сохранением возможности загрузки/выгрузки модулей. Да, это вообще идеальный вариант Ivor писал(а): Есть большое такое, конкретное предложение - сначала перевести BlackBox на slim-binaries, а уже потом заниматься кодогенерацией.
Насколько я понял, реализация slim-binaries есть в ETH Oberon. Как включить их генерацию при компиляции? |
Автор: | Иван Горячев [ Пятница, 22 Июнь, 2007 09:22 ] |
Заголовок сообщения: | |
PGR писал(а): Насколько я понял, реализация slim-binaries есть в ETH Oberon. Как включить их генерацию при компиляции?
Ручками Реализация была в Oberon for Mac, в Blackboxе её отродясь не существовало |
Автор: | PGR [ Пятница, 22 Июнь, 2007 09:52 ] |
Заголовок сообщения: | |
Ivor писал(а): Ручками Как??? Из документации "Compiling source text(s) - Compiler.Compile" Цитата: The options are:
s - Enable generation of new symbol file e - Enable generation of extended symbol file u - Suppress compilation if the object file is up-to-date w - Enable generation of warning messages |
Автор: | Иван Горячев [ Пятница, 22 Июнь, 2007 10:01 ] |
Заголовок сообщения: | |
В смысле компилятор править. И кодогенерирующий загрузчик писать. А кому сейчас легко |
Автор: | PGR [ Пятница, 22 Июнь, 2007 10:09 ] |
Заголовок сообщения: | |
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... |
Автор: | Александр Ильин [ Пятница, 22 Июнь, 2007 10:12 ] |
Заголовок сообщения: | |
Еще можно сделать удаление "мертвого" кода хотя бы на уровне процедур. Если процедура не экспортирована и нигде в модуле не используется ее идентификатор, то не генерировать для нее код. |
Автор: | Иван Горячев [ Пятница, 22 Июнь, 2007 10:25 ] |
Заголовок сообщения: | |
PGR писал(а): Почему править? Уже...
А цитата откуда? Вообще я до БлэкБокса только дома доберусь, но помнится мне, что слимы нигде в нём не фигурируют. А уж кодогенерирующего загрузчика точно нет. |
Автор: | Сергей Губанов [ Пятница, 22 Июнь, 2007 10:26 ] |
Заголовок сообщения: | |
Вот тут про inline говорят, а мне вот интересно как господа предлагают узнавать stack trace - какая процедура какую вызвала, если все процедуры заинлайнены? И уж не поэтому ли ни в Java ни в .Net никакого инлайна и в помине нету и не предвидется? |
Автор: | PGR [ Пятница, 22 Июнь, 2007 10:29 ] |
Заголовок сообщения: | |
Ivor писал(а): А цитата откуда? Вообще я до БлэкБокса только дома доберусь, но помнится мне, что слимы нигде в нём не фигурируют. А уж кодогенерирующего загрузчика точно нет. Из ETH Oberon. Цитата: Насколько я понял, реализация slim-binaries есть в ETH Oberon. Как включить их генерацию при компиляции?
|
Автор: | Иван Горячев [ Пятница, 22 Июнь, 2007 10:29 ] |
Заголовок сообщения: | |
Сергей Губанов: Смотря что инлайнить. Если простую процедуру без внутренних переменных - в чём проблема? К тому же имея полную информацию о программе в виде slim-binary много чего отследить можно. |
Автор: | Иван Горячев [ Пятница, 22 Июнь, 2007 10:32 ] |
Заголовок сообщения: | |
PGR писал(а): Из ETH Oberon.
Не заметил, прошу прощения. Про ETH не скажу, но вполне вероятно что в реальности такое существует только в версии для Mac. Но мы то о БлэкБоксе говорим? |
Автор: | PGR [ Пятница, 22 Июнь, 2007 10:39 ] |
Заголовок сообщения: | |
Ivor писал(а): Но мы то о БлэкБоксе говорим?
За основу надо же что-то взять, не делать же всё from scratch |
Страница 1 из 4 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |