к
хм, мы говорим сугубо про язык, на реализацию пока что все равно
Size: a a a
2021 March 30
к
под регистром понимается регистр в вм-ке, а не регистр проца
AT
вот у нас пустой стек: []
мы закинули два аргумента
[1, 2]
мы сделали кол, в стек попал адрес возврата, и frame pointer, текуший стал FP = 4
[1, 2, CP+1, OLDFP]
мы аллоцировали в функции 3 переменных локальных
[1, 2, CP+1, OLDFP, 0, 0, 0]
мы положили на стек результат
[1, 2, CP+1, OLDFP, 0, 0, 0, 42]
мы вычистили все локальные переменные, сбросив все до FP
[1, 2, CP+1, OLDFP]
восстановили FP до OLDFP, вернулись на CP+1
[1, 2]
результат потерялся, аргументы в стеке
мы закинули два аргумента
[1, 2]
мы сделали кол, в стек попал адрес возврата, и frame pointer, текуший стал FP = 4
[1, 2, CP+1, OLDFP]
мы аллоцировали в функции 3 переменных локальных
[1, 2, CP+1, OLDFP, 0, 0, 0]
мы положили на стек результат
[1, 2, CP+1, OLDFP, 0, 0, 0, 42]
мы вычистили все локальные переменные, сбросив все до FP
[1, 2, CP+1, OLDFP]
восстановили FP до OLDFP, вернулись на CP+1
[1, 2]
результат потерялся, аргументы в стеке
Не-не-не, у Вас же два стека?
AT
почему add какой-нибудь возвращает результат на стек, а функции в регистр какой-то
Функция кладёт результат в регистр, команда
ret делает возврат и перекладывает на стек. 😉к
Не-не-не, у Вас же два стека?
это вот я говорю про случай с одним стеком
к
у меня сейчас два стека, да, но второй стек невидим для программиста
AT
это вот я говорю про случай с одним стеком
С одним не получится без произвольной адресации. Потому в Forth их два.
AT
у меня сейчас два стека, да, но второй стек невидим для программиста
Это не значит, что ВМ не может на него класть аргументы вызова а потом читать оттуда.
к
с чисто двумя стеками тоже без произвольной адресации было не очень удобно, простейшие вещи превращались в огромное число перекидываний туда-обратно со свапами
Z
хм, мы говорим сугубо про язык, на реализацию пока что все равно
ну в том же байткоде jvm при коле забирается n аргументов, возвращается результат, и всякие адреса возврата скрыты в реализации, почему так не сделать?
AT
с чисто двумя стеками тоже без произвольной адресации было не очень удобно, простейшие вещи превращались в огромное число перекидываний туда-обратно со свапами
Welcome to the stack languages! 😂
к
ну в том же байткоде jvm при коле забирается n аргументов, возвращается результат, и всякие адреса возврата скрыты в реализации, почему так не сделать?
ну, вот сейчас так и сделано у меня, я просто сомневаюсь в хорошести этого решения
AT
ну, вот сейчас так и сделано у меня, я просто сомневаюсь в хорошести этого решения
Просто напишите JIT, который это всё соптимизирует! 😂
PS
Просто напишите JIT, который это всё соптимизирует! 😂
к
я так понимаю в jvm как раз и есть этот отдельный регистр для возвращаемого значения
Z
не понимаю как сделать стековый язык красиво
в данный момент у меня решение как раз такое как выше описано: у меня есть дата-стек, с которым работают все операции, и есть отдельный колстек, на котором лежат стекфреймы, где "стекфрейм" это адрес возврата + ссылка на собственную кучу для локальных переменных, куда идут все аргументы сразу при call
но это выглядит не очень красиво, потому что на каждую функцию собственная куча заводится, почему бы не использовать стек
но стек использовать я так понимаю нельзя, что с ebp/fp, что без него, потому что результат функции тоже возвращается через стек, регистров же нет, нельзя сбрасывать стек до ebp
вот текущее решение - https://gist.github.com/kana-sama/31a7dbcda0d434f0013e4f2227b8c895
в данный момент у меня решение как раз такое как выше описано: у меня есть дата-стек, с которым работают все операции, и есть отдельный колстек, на котором лежат стекфреймы, где "стекфрейм" это адрес возврата + ссылка на собственную кучу для локальных переменных, куда идут все аргументы сразу при call
но это выглядит не очень красиво, потому что на каждую функцию собственная куча заводится, почему бы не использовать стек
но стек использовать я так понимаю нельзя, что с ebp/fp, что без него, потому что результат функции тоже возвращается через стек, регистров же нет, нельзя сбрасывать стек до ebp
вот текущее решение - https://gist.github.com/kana-sama/31a7dbcda0d434f0013e4f2227b8c895
можно не выделять кучу на каждую функцию: запоминаем указатель стека при входе в процедуру, от него считаем локальные переменные, при выходе из процедуры копируем результат к себе, чистим стек и кладём результат обратно. Но опять же, я не понимаю вы про язык или реализацию
к
там результат кладется не на стек, а через специальный [i|d|b|...]return возвращается
PG
вот у нас пустой стек: []
мы закинули два аргумента
[1, 2]
мы сделали кол, в стек попал адрес возврата, и frame pointer, текуший стал FP = 4
[1, 2, CP+1, OLDFP]
мы аллоцировали в функции 3 переменных локальных
[1, 2, CP+1, OLDFP, 0, 0, 0]
мы положили на стек результат
[1, 2, CP+1, OLDFP, 0, 0, 0, 42]
мы вычистили все локальные переменные, сбросив все до FP
[1, 2, CP+1, OLDFP]
восстановили FP до OLDFP, вернулись на CP+1
[1, 2]
результат потерялся, аргументы в стеке
мы закинули два аргумента
[1, 2]
мы сделали кол, в стек попал адрес возврата, и frame pointer, текуший стал FP = 4
[1, 2, CP+1, OLDFP]
мы аллоцировали в функции 3 переменных локальных
[1, 2, CP+1, OLDFP, 0, 0, 0]
мы положили на стек результат
[1, 2, CP+1, OLDFP, 0, 0, 0, 42]
мы вычистили все локальные переменные, сбросив все до FP
[1, 2, CP+1, OLDFP]
восстановили FP до OLDFP, вернулись на CP+1
[1, 2]
результат потерялся, аргументы в стеке
Можете аллоцировать место на стеке в размером с тип возвращаемого значения, а в функции вместо return записывать данные по указателю
PG
можно не выделять кучу на каждую функцию: запоминаем указатель стека при входе в процедуру, от него считаем локальные переменные, при выходе из процедуры копируем результат к себе, чистим стек и кладём результат обратно. Но опять же, я не понимаю вы про язык или реализацию
Полагаю результат «скопировать» к себе вы можете только положив его на стэк.
ДК
Есть разные соглашения о вызовах. Где-то вызываемая функция подчищает за собой (восстанавливает регистры), где-то вызывающая, где-то обе - каждая свои регистры. Для простоты интеграции с сишными либами и скорости работы с ними, имеет смысл использовать то же соглашение.