Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Удалить нативные вставки #36

Closed
6 tasks done
Mazdaywik opened this issue Mar 31, 2019 · 2 comments
Closed
6 tasks done

Удалить нативные вставки #36

Mazdaywik opened this issue Mar 31, 2019 · 2 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@Mazdaywik
Copy link
Owner

Mazdaywik commented Mar 31, 2019

Эта задача — подзадача #33.

В противоположность задаче #11 предлагается удалить нативные вставки. Обоснование — в задаче #33.

Что надо сделать:

  • создать в рантайме макросы DEFINE_LOCAL_ENUM(name), DEFINE_ENTRY_ENUM(name) для определения пустых функций,
  • создать макросы DECLARE_LOCAL_FUNCTION(name), DECLARE_ENTRY_FUNCTION(name) для объявления внешних функций и ссылок вперёд для локальных,
  • создать макросы DEFINE_LOCAL_FUNCTION(name), DEFINE_ENTRY_FUNCTION(name) для определения заголовка функции,
  • использовать каждый из этих макросов в кодогенераторе,
  • переделать Library.ref в Library.c,
  • удалить поддержку нативных вставок в компиляторе.

Замечание по макросам DEFINE_…_FUNCTION(name). Их использование:

DEFINE_LOCAL_FUNCTION(Foo) {
  ...
}

DEFINE_ENTRY_FUNCTION(Bar) {
  ...
}

Они раскрываются в

static r05c_Foo(struct r05_node *arg_begin, struct r05_node *arg_end);
static r05_function r05f_Foo = { r05c_Foo, "Foo" };
static r05c_Foo(struct r05_node *arg_begin, struct r05_node *arg_end) {
  ...
}

static r05c_Bar(struct r05_node *arg_begin, struct r05_node *arg_end);
r05_function r05f_Bar = { r05c_Bar, "Bar" };
static r05c_Bar(struct r05_node *arg_begin, struct r05_node *arg_end) {
  ...
}

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

@Mazdaywik Mazdaywik added the enhancement New feature or request label Mar 31, 2019
@Mazdaywik Mazdaywik added this to the 4.0 milestone Mar 31, 2019
@Mazdaywik Mazdaywik self-assigned this Mar 31, 2019
@Mazdaywik
Copy link
Owner Author

В дополнение к критике нативных вставок в #33. Нативные вставки раскрываются в

    #line 7 "native-hello.ref"
      printf("Hello, World!\n");
      r05_splice_to_freelist(arg_begin, arg_end);
    #line 15 "native-hello.c"

Нативная вставка предваряется директивой #line с именем исходного файла и номером строки, что немного усложняет лексический анализ. Также усложняется кодогенерация, поскольку приходится генерировать вторую #line с номером строки и именем целевого файла.

Mazdaywik added a commit that referenced this issue Apr 1, 2019
Начиная с этого коммита, нативные вставки — недокументированное расширение
компилятора.
Mazdaywik added a commit that referenced this issue Apr 1, 2019
1. Их поддержка удалена из лексера, поэтому исходные файлы с нативными
   вставками не компилируются. Поэтому компилятор их не поддерживает.
2. Из интерфейса (документирующих комментариев) удалены упоминания нативных
   вставок, поэтому компоненты фреймворка их тоже не поддерживают.
   (Их можно считать недокументированным расширением парсера и генератора.)

После этого коммита большинство дальнейших упрощений можно будет честно
называть рефакторингами — они не будут затрагивать поведение компилятора
и задокументированный интерфейс.
Mazdaywik added a commit that referenced this issue Apr 1, 2019
Формально это не рефакторинг, поскольку менялся документированный
интерфейс. Но по сути это рефакторинг.
@Mazdaywik
Copy link
Owner Author

Удалось достичь небольшого, но измеримого повышения быстродействия. Сравнивались коммиты 3f4aee2 и 81e2173.

До рефакторинга и почти рефакторинга время Рефала составляло 5,645 секунд (квартили 5,567–5,820), после — 5,391 секунда (5,175–5,529). Ускорение произошло преимущественно из-за поиска нативных вставок открытыми переменными (в лексере и генераторе), время циклов, соответственно, 0,545 (0,515–0,607) и 0,404 (0,329–0,486). Доверительные интервалы показывают, что ускорение достоверное.

Но я делал эту оптимизацию не для ускорения, тем более, что (#34) имеющиеся лексер и парсер будут выкинуты и заменены на сторонние и более медленные. Мне просто было интересно померить и убедиться.

Методику тестирования описывать лень, просто приложу файлы из папки src:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant