Здравствуйте, hardcase, Вы писали:

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

Здравствуйте, WolfHound, Вы писали:

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

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

Здравствуйте, VladD2, Вы писали:

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

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

Здравствуйте, VladD2, Вы писали:

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

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

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

Здравствуйте, Воронков Василий, Вы писали:

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

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


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

Здравствуйте, BogdanMart, Вы писали:

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

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

Здравствуйте, BogdanMart, Вы писали:

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

Здравствуйте, BogdanMart, Вы писали:

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

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

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

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

Здравствуйте, Воронков Василий, Вы писали:

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

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

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

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

Приходиться разбирать байткод, потом оптимизировать. А байткод зачастую далеко не оптимальный (Самый чисты байткод у 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 точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.

Здравствуйте, BogdanMart, Вы писали:

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

BM>Помоему компиляция из такого байткода в реальные инструкции -- ад
Не сложнее чем из исходника на C#.

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

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

Здравствуйте, 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 точнее), оперировали бы они перемеными а не стеком, было бы проще генерировать машинный код на его основе.

Эту мысль я не понял.

Здравствуйте, 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-оптимизатор.

Здравствуйте, hardcase, Вы писали:

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

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

Здравствуйте, catbert, Вы писали:

C>У нас ведь CFG есть вроде?
Лучшеб его небыло. Глючит страшно.

Здравствуйте, catbert, Вы писали:

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

Он глючный и почти бесполезный для генерирования IL, так как работает на уровне TExpr.

Здравствуйте, Мишень-сан, Вы писали:

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

Все прозаичнее. Байткод банально компактнее. А так, он тоже описывает некую модель. Так что никакой разницы нет.

Здравствуйте, Воронков Василий, Вы писали:
ВВ>Нет, вы пожалуйста продолжайте. Приведите, пожалуйста, 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

немного странно

Но как видно ведет он себя непредсказуемо

Здравствуйте, BogdanMart, Вы писали:

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

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

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

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

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

Ну а про компактность тут уже много раз сказали.

Здравствуйте, WolfHound, Вы писали:

C>>У нас ведь CFG есть вроде?
WH>Лучшеб его небыло. Глючит страшно.

Это еще ладно. Главное что он написан так, что кроме автора его мало кто может понять. И при этом он еще практически ничего не делает. Точнее то что он делает делает и джит.

Здравствуйте, _nn_, Вы писали:

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

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

А это не будет конфликтовать с квазицитированием?