Size: a a a

Compiler Development

2020 January 13

FO

FORTRAN ONE LOVE in Compiler Development
Valerii
63 года в этой теме!
признанный фаворит вычислителей!
обширные инфраструктурные связи!
никакого алисаинга!
лично повлиял на стандартные обозначения в математике!
никакого алисаинга!

Ой как Вы ошибаетесь...
источник

V

Valerii in Compiler Development
ну я про
int a[5];
int* b = a[3];

не большой знаток фортрана)
источник

FO

FORTRAN ONE LOVE in Compiler Development
Valerii
ну я про
int a[5];
int* b = a[3];

не большой знаток фортрана)
Вот я это в фортране делаю. Выше даже есть пример кода
источник

FO

FORTRAN ONE LOVE in Compiler Development
Valerii
ну я про
int a[5];
int* b = a[3];

не большой знаток фортрана)
источник

V

Valerii in Compiler Development
интересно, спасибо
источник

VY

Vasiliy Yorkin in Compiler Development
Какой должен быть "тип" (statement vs expression) у IR, сгенерированного для следующего "выражения"
if a > b then b > c else b := d
?
Т.е. это должен быть стейтмент или выражение (которое возвращает 0, например)?
У каждого варианта есть свой минус:
1) Если выбрать "сгенерировать" IR для выражения, то в else-ветке можно возвращать 0, но это немного странно. Не представляю как может возникнуть желание писать что-то типа
if (if a > b then b > c else b := 0) then ... else ...
2) Если выбрать "сгенерировать" IR для стейтмента, то придётся игнорировать результат выражения then-ветки (b > c)

(неуверен, что я понятно задал вопрос)
источник

E

EgorBo in Compiler Development
я вижу тут три стейтмента в трех бб
источник

E

EgorBo in Compiler Development
можно как ллвм вводить вспомогающие конструкции аля селект
источник

BD

Berkus Decker in Compiler Development
Михаил Бахтерев
Ну так это решается семафорами. А когда говорят о свободе от блокировок, то стремятся прежде всего к скорости
нет, неблокирующие операции (lock-free) обычно медленнее. Гонятся, внезапно, за отсутствием блокировок.
источник

AT

Alexander Tchitchigin in Compiler Development
Vasiliy Yorkin
Какой должен быть "тип" (statement vs expression) у IR, сгенерированного для следующего "выражения"
if a > b then b > c else b := d
?
Т.е. это должен быть стейтмент или выражение (которое возвращает 0, например)?
У каждого варианта есть свой минус:
1) Если выбрать "сгенерировать" IR для выражения, то в else-ветке можно возвращать 0, но это немного странно. Не представляю как может возникнуть желание писать что-то типа
if (if a > b then b > c else b := 0) then ... else ...
2) Если выбрать "сгенерировать" IR для стейтмента, то придётся игнорировать результат выражения then-ветки (b > c)

(неуверен, что я понятно задал вопрос)
Это просто не должно тайпчекаться. 😊
источник

M

MaxGraey in Compiler Development
EgorBo
maxgraey наверное на обеде :D
Так, попрошу. Я не растофил, я асемблискритофил =) Прошу не путать!
источник

VY

Vasiliy Yorkin in Compiler Development
EgorBo
можно как ллвм вводить вспомогающие конструкции аля селект
Я ещё не дочитал до главы про базовые блоки и довольно плохо знаю ллвм :(
источник

VY

Vasiliy Yorkin in Compiler Development
Alexander Tchitchigin
Это просто не должно тайпчекаться. 😊
И правда, оно у меня не тайпчекнется даже
  and tr_cond cond t f ~env =
   Trace.SemanticAnalysis.tr_cond cond t f;
   assert_int cond ~env;
   let { ty = t_ty; _ } = tr_expr t ~env in
   match f with
   | None ->
     ret e_dummy t_ty
   | Some f ->
     (* If there is a false-branch then we should
        check if types of both branches match *)
     let { ty = f_ty; _ } = tr_expr f ~env in
     if T.(t_ty = f_ty)
     then ret e_dummy t_ty
     else type_error expr @@ sprintf
         "different types of branch expressions: \"%s\" and \"%s\""
         (T.to_string t_ty) (T.to_string f_ty)

Тогда и думать об этом не надо, на фазу IR оно не пройдёт
источник

E

EgorBo in Compiler Development
MaxGraey
Так, попрошу. Я не растофил, я асемблискритофил =) Прошу не путать!
поздно, когда дают клички, вешают ярлыки — не спрашивают человека :p
источник

AT

Alexander Tchitchigin in Compiler Development
Vasiliy Yorkin
И правда, оно у меня не тайпчекнется даже
  and tr_cond cond t f ~env =
   Trace.SemanticAnalysis.tr_cond cond t f;
   assert_int cond ~env;
   let { ty = t_ty; _ } = tr_expr t ~env in
   match f with
   | None ->
     ret e_dummy t_ty
   | Some f ->
     (* If there is a false-branch then we should
        check if types of both branches match *)
     let { ty = f_ty; _ } = tr_expr f ~env in
     if T.(t_ty = f_ty)
     then ret e_dummy t_ty
     else type_error expr @@ sprintf
         "different types of branch expressions: \"%s\" and \"%s\""
         (T.to_string t_ty) (T.to_string f_ty)

Тогда и думать об этом не надо, на фазу IR оно не пройдёт
Вот именно! Чем больше НЕ тайпчекается - тем меньше проблем у компилятора. 😂
источник

VY

Vasiliy Yorkin in Compiler Development
Я чёт просто настолько углубился в трансляцию в IR, что начал рассматривать все возможные варианты как сгенерировать код для условных выражений и забыл про всё остальное
источник

VY

Vasiliy Yorkin in Compiler Development
%)
источник

E

EgorBo in Compiler Development
сохрани слфетки, потом если что в музеи будут лежать
источник

VY

Vasiliy Yorkin in Compiler Development
Хм, хотя у меня в tiger a <rel_op> b : int и
(b : B := init : B) : B
т.е. можно писать так
let x := (if a > b then b > c else c := d) in ...
т.е. оно тайпчекнется (если (c := d) : int)
ок, я кажется понял что делать %)
источник

AT

Alexander Tchitchigin in Compiler Development
Vasiliy Yorkin
Хм, хотя у меня в tiger a <rel_op> b : int и
(b : B := init : B) : B
т.е. можно писать так
let x := (if a > b then b > c else c := d) in ...
т.е. оно тайпчекнется (если (c := d) : int)
ок, я кажется понял что делать %)
А это специально в Tiger прописано, что нет типа bool и вместо него int как в C?
источник