Лингвофорум

Цитата: myst от декабря  4, 2010, 18:48

ЦитироватьТак изменил исходник да перекомпилировал, я не понял, в чём проблема.

Хочеццо мышкой вжик-вжик, и всё.

Я не понимаю, о чём ты. Мышкой вжик-вжик сделал, и перекомпилировал.

Приведи конкретный пример, я не понимаю.

Цитата: Алексей Гринь от декабря  4, 2010, 19:06
Я не понимаю, о чём ты. Мышкой вжик-вжик сделал, и перекомпилировал.

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

Мне сложно говорить на такие темы по русски, ибо привык по-английски. С трудом пониманию все эти кривые переводы терминов.

Цитата: myst от декабря  4, 2010, 19:08
Мышкой вжик-вжик сделал и продолжил работу, не заморачиваясь перекомпиляцией и исходниками.

Я наконец-то понял. Т.е. ты предлагаешь так:

Есть либа, допустим functional.dll.
К ней лицом прикручены gui.exe и console.exe, так?

Ну тут можно сделать загрузку байткода из raw-файла. При том что VM до сих пор сидит полностью в главном EXE.

Цитата: Алексей Гринь от декабря  4, 2010, 19:13
Мне сложно говорить на такие темы по русски, ибо привык по-английски. С трудом пониманию все эти кривые переводы терминов.

Ты про вжик-вжик?

Цитата: Алексей Гринь от декабря  4, 2010, 19:15
Я наконец-то понял. Т.е. ты предлагаешь так:

Есть либа, допустим functional.dll.
К ней лицом прикручены gui.exe и console.exe, так?

Ну тут можно сделать загрузку байткода из raw-файла. При том что VM до сих пор сидит полностью в главном EXE.

Для щастья должно быть всё в одном флаконе, в системе естественно должен быть редактор флакона, интерфейс (и текстовый и графический) описывается декларативно на специальном языке, для графического ещё редактор интерфейса (для вжик-вжик) не помешает. Для всех программных интерфейсов должна быть спецификация прямо во флаконе.

Цитата: myst от декабря  4, 2010, 19:23
интерфейс (и текстовый и графический) описывается декларативно на специальном языке, для графического ещё редактор интерфейса (для вжик-вжик) не помешает

Ну это, по-моему, задача за пределами VMExecution Engine (EE). Это уже какие-то конкретные реализации/спецификации должны быть поверх EE. И тут, кстати, динамика пригодится: можно конструировать классы, читая текстовый файл спецификации.

Я вот хочу ядро EE сделать без стандартной либы вообще (в отличие от .NET, который без мегабайтного mscorlib.dll не хочет грузиться, хотя функционала мне нужно 1%, напр.). Может быть, засунуть только поддержку строк, потоков и мьютексов в разряд примитивов. А ты тут предлагаешь такую замуту

Цитата: Алексей Гринь от декабря  4, 2010, 19:38
Ну это, по-моему, задача за пределами VMExecution Engine (EE). Это уже какие-то конкретные реализации/спецификации должны быть поверх EE. И тут, кстати, динамика пригодится: можно конструировать классы, читая текстовый файл спецификации.

Ну да, я размечтался о наболевшем.

Цитата: arseniiv от декабря  4, 2010, 19:41
Даёшь быстроту! Её скоро станет ощутимо не хватать.

Когда станут доступны 16-ядерные 5 ваттовые атомы?

Цитата: arseniiv от декабря  4, 2010, 20:43
Когда-нибудь прогресс процессоров начнёт замедляться. А квантовые компьютеры пока что нарисованы на воде.

Когда-нибудь != скоро.

Короче, архитектура кодогенерации оказалась такова, что кешировать аргументы в регистры нет смысла. Посмотрим, что насчёт локальных переменных.

Так-с, архитектура работает вроде, впендюривать оптизимацию очень легко.

C#:
int f(int a, int b) { return a + b + 13; }

Байткод:
ILDARG 0
ILDARG 1
IADD
ILDC32 13
IADD
RET

выворачивается в:
push ebp
mov ebp, esp
sub esp, 8 <-- издержки дебуга, не обращаем внимание
push ecx
mov eax, [ebp+08]
mov ecx, [ebp+0C]
add eax, ecx
add eax, 13
pop ecx
leave
ret 8

Сие является результатом пары доп. строчек (которые, отвлекаясь, я писал весь вечер), что позволило ускориться аж на 16.8% по сравнению с предыдущим состоянием.
Вроде теперь не стыдно людям в глаза смотреть.
Или нет?

Что странно, ровно на 16.8% результат получился быстрее дебуг-билда аналога на mingw-c. Или мозг уже ничё не соображает, или совпадение...