Re[2]: Nemerle 2.0
От: WolfHound  
Дата: 21.01.11 15:02
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Интересная ссылка.

Полезной информации ноль целых хрен десятых.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Nemerle 2.0
От: VladD2 Российская Империя www.nemerle.org
Дата: 21.01.11 15:40
Оценка:
Здравствуйте, WolfHound, Вы писали:

H>>Интересная ссылка.

WH>Полезной информации ноль целых хрен десятых.

Я беглым взглядом пробежался и мне тоже так показалось, но не хочет быть столь же категоричным. Может Хардкейс что-то конкретное имел в виду.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Nemerle 2.0
От: hardcase Пират http://nemerle.org
Дата: 21.01.11 15:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я беглым взглядом пробежался и мне тоже так показалось, но не хочет быть столь же категоричным. Может Хардкейс что-то конкретное имел в виду.


Просто, документик заинтересовал, но ничего конкретного Раз такие дела, ветку можно прикрыть за ненадобностью.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Re: Nemerle 2.0
От: _nn_ www.nemerleweb.com
Дата: 26.06.11 10:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Просьбы не засорять тему обсуждениями (открывайте другие темы). Эта тема — копилка того что нужно не забыть реализовать в 2.0 и для серьезных вопросов.


Убрать хардкод с '$'.

(Невозможно создать макрос начинающийся с '$' )
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[3]: Вынести процесс генерации MSIL-а в отдельную стадию
От: BogdanMart Украина  
Дата: 26.06.11 12:48
Оценка:
Здравствуйте, Воронков Василий, Вы писали:

ВВ>В идеале мне кажется сделать свой бэкенд — как минимум свой байт-код — и компилировать в него.


Зачем свой байткод, если есть AST ?


зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.
Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
От: Мишень-сан  
Дата: 27.06.11 05:55
Оценка:
Здравствуйте, BogdanMart, Вы писали:

BM>зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.


Наверное потому, что AST разных языков может отличаться. Байткод более низкоуровневый, а потому более универсальный.
Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
От: WolfHound  
Дата: 27.06.11 09:07
Оценка: +2
Здравствуйте, BogdanMart, Вы писали:

BM>зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.

Байткод это сериализованный АСТ языка MSIL.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Вынести процесс генерации MSIL-а в отдельную стадию
От: Воронков Василий Россия  
Дата: 27.06.11 09:48
Оценка: +1
Здравствуйте, BogdanMart, Вы писали:

BM>Зачем свой байткод, если есть AST ?


В данном случае — необязательно именно байт-код, можно и АСТ. Вот только все равно придется делать "свое" абстрактное АСТ.

BM>зы. (офтопик) не понятно зачем вообще байткоди почему макфрософт не хранить в бинарниках щасериализорованое АСТ.


АСТ какого языка хранить в бинарнике?
Даже если бы язык был один, байт-код есть уже результат первичной компиляции, к которому был применен ряд оптимизаций. Его компиляция произойдет быстрее (или интерпретация).
Наконец байт-код тупо компактнее.
Re[5]: Вынести процесс генерации MSIL-а в отдельную стадию
От: BogdanMart Украина  
Дата: 27.06.11 21:29
Оценка: :)
Здравствуйте, Воронков Василий, Вы писали:

ВВ>АСТ какого языка хранить в бинарнике?

ВВ>Даже если бы язык был один, байт-код есть уже результат первичной компиляции, к которому был применен ряд оптимизаций. Его компиляция произойдет быстрее (или интерпретация).
ВВ>Наконец байт-код тупо компактнее.

Какой то очень абстрактный и низкоуровневый.

Просто не понятно чем стековая машинатакая крутая?

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

Приходиться разбирать байткод, потом оптимизировать. А байткод зачастую далеко не оптимальный (Самый чисты байткод у Managed C++)

Но JIT'c довольно однозначно, но в тупую транслирует байткод и результат получаеться довольно далек от оптимума(ох я и поржал над его результатами)

например такой код

call MethodName
stloc.3
ldloc.3
.....

после вызова делает
mov [ebp+6], eax //stloc.3
mov eax, [ebp+6] //ldloc.3

Что, согласитесь, совсем не оптимально потому что байткод уже оптимизироавть почтине реально и CLR втупую странслирует его на асм.


еслибы сгенерить хотябы
dup
stloc.3

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

А я про сам байткод (MSIL точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.
Re[6]: Вынести процесс генерации MSIL-а в отдельную стадию
От: WolfHound  
Дата: 27.06.11 22:01
Оценка: +1
Здравствуйте, BogdanMart, Вы писали:

BM>Просто не понятно чем стековая машинатакая крутая?

Это самое компактное представление кода.

BM>Помоему компиляция из такого байткода в реальные инструкции -- ад

Не сложнее чем из исходника на C#.

BM>Что, согласитесь, совсем не оптимально потому что байткод уже оптимизироавть почтине реально и CLR втупую странслирует его на асм.

То что JIT хреново оптимизирует с этим не поспоришь.
То что это вина байткода ты не прав.

BM>А я про сам байткод (MSIL точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.

Стековую машину можно превратить в регистровую за один проход тупейшим алгоритмом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Вынести процесс генерации MSIL-а в отдельную стадию
От: Воронков Василий Россия  
Дата: 28.06.11 04:50
Оценка:
Здравствуйте, BogdanMart, Вы писали:

ВВ>>АСТ какого языка хранить в бинарнике?

ВВ>>Даже если бы язык был один, байт-код есть уже результат первичной компиляции, к которому был применен ряд оптимизаций. Его компиляция произойдет быстрее (или интерпретация).
ВВ>>Наконец байт-код тупо компактнее.
BM>Какой то очень абстрактный и низкоуровневый.
BM>Просто не понятно чем стековая машинатакая крутая?

В смысле "чем крутая"? Для кого крутая? Технически, основной плюс — компактность инструкций по сравению с регистровой.

BM>Помоему компиляция из такого байткода в реальные инструкции -- ад


Обычная трансляция из стекового байткода в регистровый. И ее можно произвести *гораздо* быстрее, чем многопроходную первоначальную компиляцию в MSIL. Липперт как-то писал о том, сколько стадий у компилятора C#.

BM>Приходиться разбирать байткод, потом оптимизировать. А байткод зачастую далеко не оптимальный (Самый чисты байткод у Managed C++)


И что?

BM>Но JIT'c довольно однозначно, но в тупую транслирует байткод и результат получаеться довольно далек от оптимума(ох я и поржал над его результатами)


Как проверяли? Очень похоже на запуск дебуг версии.

BM>еслибы сгенерить хотябы

BM>dup
BM>stloc.3
BM>Тогда можно изббежать лишнего чтения из локальной переменной, но это уже про корявость компиляторов управляемых.

Нет, вы пожалуйста продолжайте. Приведите, пожалуйста, x86 код, в который скомпилируется dup stloc.3

BM>А я про сам байткод (MSIL точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.


Эту мысль я не понял.
Re[6]: Вынести процесс генерации MSIL-а в отдельную стадию
От: hardcase Пират http://nemerle.org
Дата: 28.06.11 06:52
Оценка: +1
Здравствуйте, BogdanMart, Вы писали:

BM>например такой код


BM>call MethodName

BM>stloc.3
BM>ldloc.3
BM>.....

BM>после вызова делает

BM>mov [ebp+6], eax //stloc.3
BM>mov eax, [ebp+6] //ldloc.3

BM>Что, согласитесь, совсем не оптимально потому что байткод уже оптимизироавть почтине реально и CLR втупую странслирует его на асм.


Байткод оптимизировать вполне реально, и по сути это лишь проблема конкретных кодогенераторов. Если тебе не нравится, какой код генерирует Nemerle можешь вполне закопаться в ILEmitter (который на самом деле стоит просто выбросить) — нам не точно не помешает объектная модель IL и CFG-оптимизатор.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Re[7]: Вынести процесс генерации MSIL-а в отдельную стадию
От: catbert  
Дата: 28.06.11 09:33
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Байткод оптимизировать вполне реально, и по сути это лишь проблема конкретных кодогенераторов. Если тебе не нравится, какой код генерирует Nemerle можешь вполне закопаться в ILEmitter (который на самом деле стоит просто выбросить) — нам не точно не помешает объектная модель IL и CFG-оптимизатор.


У нас ведь CFG есть вроде?
http://nemerle.org/banners/?t=%20catbert%20
Re[8]: Вынести процесс генерации MSIL-а в отдельную стадию
От: WolfHound  
Дата: 28.06.11 09:57
Оценка: +1
Здравствуйте, catbert, Вы писали:

C>У нас ведь CFG есть вроде?

Лучшеб его небыло. Глючит страшно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Вынести процесс генерации MSIL-а в отдельную стадию
От: hardcase Пират http://nemerle.org
Дата: 28.06.11 10:22
Оценка:
Здравствуйте, catbert, Вы писали:

C>У нас ведь CFG есть вроде?


Он глючный и почти бесполезный для генерирования IL, так как работает на уровне TExpr.
http://nemerle.org/Banners/?t=Developer!&g=dark /* иЗвиНите зА неРовнЫй поЧерК */
Re[5]: Вынести процесс генерации MSIL-а в отдельную стадию
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.06.11 14:39
Оценка:
Здравствуйте, Мишень-сан, Вы писали:

МС>Наверное потому, что AST разных языков может отличаться. Байткод более низкоуровневый, а потому более универсальный.


Все прозаичнее. Байткод банально компактнее. А так, он тоже описывает некую модель. Так что никакой разницы нет.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Вынести процесс генерации MSIL-а в отдельную стадию
От: BogdanMart Украина  
Дата: 28.06.11 15:06
Оценка:
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нет, вы пожалуйста продолжайте. Приведите, пожалуйста, x86 код, в который скомпилируется dup stloc.3

Чертовски странно, раньше я видел другой результат, но сегодня немного по дебльному сгенерировало А в не отладочном проверить не получилось, так как в нем отладчик вообще нивкакую не подключаеться

    stloc.0
00000035  mov         eax,dword ptr [ebp-30h] 
00000038  mov         dword ptr [ebp-2Ch],eax 
    ldloc.0             // Load local variable 0 onto stack
0000003b  mov         eax,dword ptr [ebp-2Ch] 
0000003e  mov         dword ptr [ebp-34h],eax 
    ldc.i4.0            // Load constant 0 to the stack 
00000041  xor         edx,edx 
00000043  mov         dword ptr [ebp-0Ch],edx 
    ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
00000046  mov         dword ptr [ebp-10h],0Ah

30h и 34h это походу стек ИЛа)))
    dup
00000035  nop              
    stloc.0
00000036  mov         eax,dword ptr [ebp-30h] 
00000039  mov         dword ptr [ebp-2Ch],eax 
0000003c  mov         eax,dword ptr [ebp-2Ch] 
0000003f  mov         dword ptr [ebp-34h],eax 
    ldc.i4.0            // Load constant 0 to the stack 
00000042  xor         edx,edx 
00000044  mov         dword ptr [ebp-0Ch],edx 
    ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
00000047  mov         dword ptr [ebp-10h],0Ah



в режиме х64
    stloc.0
00000042  mov         qword ptr [rsp+20h],rax 
    ldloc.0             // Load local variable 0 onto stack
00000047  nop              
    ldc.i4.0            // Load constant 0 to the stack 
00000048  nop              
    ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
00000049  nop
оно дофига шарит, хотя раньше в этом режиме выдавало такие перлы...))

00000042  mov         qword ptr [rsp+30h],rax 
         dup
00000047  mov         rax,qword ptr [rsp+30h] 
    stloc.0
0000004c  mov         qword ptr [rsp+20h],rax 
    ldc.i4.0            // Load constant 0 to the stack 
00000051  nop              
    ldc.i4.s   10        // Load constant 10 to the stack (s form is used for n > 8)
00000052  nop
немного странно

Но как видно ведет он себя непредсказуемо
Re[8]: Вынести процесс генерации MSIL-а в отдельную стадию
От: Воронков Василий Россия  
Дата: 29.06.11 08:20
Оценка:
Здравствуйте, BogdanMart, Вы писали:

BM>Чертовски странно, раньше я видел другой результат, но сегодня немного по дебльному сгенерировало А в не отладочном проверить не получилось, так как в нем отладчик вообще нивкакую не подключаеться


Билдите релиз, запускаете его *без отладчика*, потом — аттач отладчиком. Если не получается -можно тупо вставить в код Debugger.Break.

А по поводу dup — это я к тому, что dup на самом деле ни фига не оптимизация. Я с ним игрался, так код еще медленнее получается.

Наконец на самом деле даже не важно, насколько эффективный байт-код генерирует компилятор. Он может его вообще не оптимизаровать. Важнее то, что байт-код более низкоуровневый, чем конкретный язык.

Скажем, в таком высокоуровневом языке как Немерле на уровне АСТ будут такие конструкции как ПМ. Компилятор на уровне байт-код просто превратит их в цепочку условных переходов — при этом сделает кучу проверок, типизирует выражение, проверит достижимость отдельных веток матча и пр. И компилировать уже сам байт-код в машинный код будет тупо быстрее.

Ну а про компактность тут уже много раз сказали.
Re[9]: Вынести процесс генерации MSIL-а в отдельную стадию
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.06.11 20:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>У нас ведь CFG есть вроде?

WH>Лучшеб его небыло. Глючит страшно.

Это еще ладно. Главное что он написан так, что кроме автора его мало кто может понять. И при этом он еще практически ничего не делает. Точнее то что он делает делает и джит.
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Nemerle 2.0
От: catbert  
Дата: 29.06.11 20:42
Оценка:
Здравствуйте, _nn_, Вы писали:

__>Убрать хардкод с '$'.


__>(Невозможно создать макрос начинающийся с '$' )


А это не будет конфликтовать с квазицитированием?
http://nemerle.org/banners/?t=%20catbert%20
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.