Oberon space
General Category => Общий раздел => Тема начата: vlad от Март 09, 2011, 03:34:12 pm
-
Сейчас, вроде, сделано так, что все функции всегда возвращают результат в регистрах проца. Если разрешить функциям возвращать записи, то этой эффективной реализации придёт кирдык. :)
Неправда :) Сейчас функции "возвращают" записи как VAR-параметр. Так что вопрос сугубо синтаксический. Никто не мешает компилятору по-прежнему использовать VAR-параметр, просто но будет скрытый. А с точки зрения синтаксиса - все будет единообразно.
-
Неправда :) Сейчас функции "возвращают" записи как VAR-параметр.
VAR-параметры передаются по ссылке. И эту ссылку функция возвращает в регистре.
Если делать тоже самое, но только закулисно (синтакисически возвращать якобы по значению), то будет только хуже. Ибо, не явная муть :)
-
Неправда :) Сейчас функции "возвращают" записи как VAR-параметр.
VAR-параметры передаются по ссылке. И эту ссылку функция возвращает в регистре.
Если делать тоже самое, но только закулисно (синтакисически возвращать якобы по значению), то будет только хуже. Ибо, не явная муть :)
Я таки дико извиняюсь, но где это в описании языка сказано? :-)
Кроме того, процессоры (как реальные так и виртуальные) могут регистров не иметь вообще. Кроме того, если уж программист так заботится о быстродействии и если у него регистровый процессор и если компилятор компилит именно так, то ничто не мешает ему таки не возвращать по значению жиррные записи (не жирные могут вполне поместиться в регистр -- регистры и 64 и 128 бит бывают, так что какой-нибудь (x,y) туда вполне влезет).
-
Я таки дико извиняюсь, но где это в описании языка сказано? :-)
Гы-гы-гы :D Сырцы - это продолжение описания.
Но смотрел давно, мог и подзабыть. Не зря же в первом своём сообщении написал "вроде".
Реальные процы (в отличие от виртуальных машин), как правило, регистровые. Ибо никто заранее не знает какой глубины стек понадобится.
-
Сырцы чего именно, извините? :-)
Компиляторов Оберона ну очень много.
-
Неправда :) Сейчас функции "возвращают" записи как VAR-параметр.
VAR-параметры передаются по ссылке. И эту ссылку функция возвращает в регистре.
Да не надо ей ничего возвращать в регистре. Было:
VAR r: Record;
...
f(r);
x := f.field;
С новым синтаксисом стало:
x := f().field;
Что сделал компилятор:
VAR compiler_generated: Record;
...
f(compiler_generated);
x := compiler_generated.field;
Внутри функции было:
PROCEDURE f(VAR r: Record)
...
r.field := 0;
C новым синтаксисом:
PROCEDURE f(): Record;
VAR r: Record
...
r.field := 0;
RETURN r;
Что сделал компилятор:
PROCEDURE f(VAR r: Record);
...
r.field := 0;
-
Сырцы чего именно, извините? :-)
Блэкбокс.
-
Сырцы чего именно, извините? :-)
Блэкбокс.
Ну, ББ это вообще КП, что не совсем оберон :-). А у КП всего две реализации вроде бы – ББ и GPCP.
-
C новым синтаксисом:
PROCEDURE f(): Record;
VAR r: Record
...
r.field := 0;
RETURN r;
Не понял. Туплю что-то :)
Как процедура вернёт r, ведь после возврата из процедуры её кадр (вместе с локальной переменной r) будет снят со стека.
-
Ну, ББ это вообще КП, что не совсем оберон :-).
Да, но правила для обероновских функций, думаю, писАлись с оглядкой на те детали реализации, которые я напомнил.
-
C новым синтаксисом:
PROCEDURE f(): Record;
VAR r: Record
...
r.field := 0;
RETURN r;
Не понял. Туплю что-то :)
Как процедура вернёт r, ведь после возврата из процедуры её кадр (вместе с локальной переменной r) будет снят со стека.
Здесь 'r' расположена на стэке, да. Но на стэке вызывающей процедуры. И эта вызывающая процедура (неявно) передает 'r' вызываемой через (неявный) VAR параметр.
Можно рассмотреть более сложный вариант, когда у вас в процедуре больше одного экземпляра Record, процедура работает с этими экземплярами, а потом решает - какой и них она "вернет" (если она имеет несколько RETURN). В этом случае без копирования не обойтись. Но вы без копирования не обойдетесь и в случае, когда у вас нет такого синтаксиса (в случае "классического" VAR параметра).
-
Здесь 'r' расположена на стэке, да. Но на стэке вызывающей процедуры. И эта вызывающая процедура (неявно) передает 'r' вызываемой через (неявный) VAR параметр.
Хм... Интересно. Но вызывающих процедур (и вызываемых!) может быть много. К тому же, вызов может быть из блока-модуля, у которого и стека-то как бы нет.
Можно рассмотреть более сложный вариант, когда у вас в процедуре больше одного экземпляра Record, процедура работает с этими экземплярами, а потом решает - какой и них она "вернет" (если она имеет несколько RETURN). В этом случае без копирования не обойтись. Но вы без копирования не обойдетесь и в случае, когда у вас нет такого синтаксиса (в случае "классического" VAR параметра).
Весь вопрос в том, стоит ли игра свеч. В смысле, перевешивают ли достоинства предлагаемого решения те недостатки, которые связаны с усложнением реализации. ;)
-
Хм... Интересно. Но вызывающих процедур (и вызываемых!) может быть много. К тому же, вызов может быть из блока-модуля, у которого и стека-то как бы нет.
Так не бывает, что у вызывающей нет стэка, а у вызываемой есть. Откуда он берется? :) Если вызывающих много - то у них все равно у каждой свой участок стэка...
Весь вопрос в том, стоит ли игра свеч. В смысле, перевешивают ли достоинства предлагаемого решения те недостатки, которые связаны с усложнением реализации. ;)
Да каое ж там усложнение? Чай не плюсовые шаблоны... :)
-
Так не бывает, что у вызывающей нет стэка, а у вызываемой есть. Откуда он берется? :)
В программе обычно один стек на все модули. Этот стек конечно есть всегда, но до вызова любой первой процедуры он пуст.
Вероятно, Вы имели в виду (в своём примере), что пролог вызова процедуры и выделит место под r на вершине стека перед тем, как загрузить туда фактические параметры.
Вобщем, технически осуществимо, и я с этим с самого начала и не спорил. Свои сомнения я высказал только по поводу эффективности такого решения.