> Забавно. Почему я не в курсе ловле на пустозвонстве( хотя в предыдущие
> разы ты славно попадался на подмене понятий ) Потому что у тебя проблемы с памятью https://www.opennet.ru/openforum/vsluhforumID3/124773.html#51 (заметь, что пруфы просил не я, я их за тебя предоставил; но там малость неувязка по срокам санкций, длиною в треть твоей жизни), при этом ты очень хорошо умеешь в "а нас то за шо?", что как бэ намекает.
> Кстати, о пустозвонстве..
>> Ещё раз читаем внимательно. ИНТЕРПРЕТАТОР. Какое отношение имеет стек JS-машины к стеку процессора?
> Помнишь ?
> Ты ведь фундаментально не прав, ведь там и далеко не только интерпретатор
> и сгенерированный код к стеку проца имеет самое прямое отношение. Но..
> признался ли хоть в чем-то ?)
Я прав в том, что сам ты ничего в данном направлении не сделал, нахватался по верхам и теперь пытаешься натянуть какое-то выдуманное тобой "там" на абстрактную JIT-компиляцию. Если бы ты создал интерпретатор и подумал над тем, как согласовать с существующей ВМ (про сборщик мусора замнём для ясности) сгенерированный на лету машинный код, ты бы сам дошёл: избавляться в нём от стека ВМ означает "иметь два стека", что накладно и нецелесообразною.
> Однозначно достаточным не является, но наличие в браузере генератора машинного кода для
> разных архитектур и его применение для генерации кода уже ощутимо повышает
> шансы, поскольку речь о вызове-таки нативных функций
Хватит рассуждать о теорвере, покажи код, где стек JS-машины адресуется через rsp. Вот как в моём примере, который я привёл от нечего делать: https://www.opennet.ru/openforum/vsluhforumID3/124820.html#106
>> что ошибся со знаком смещения от регистра стека,
> Возможно, кому-то стоит меньше придираться к мелочам если есть что сказать по
> сути. Так меньше шансов оказаться невеждой( притом, невоспитанным ).
Суть вопроса проста. Кто утверждение заявляет, тот его и подтверждает. Данный случай не тот, где приходится принимать слова на веру. Если JS машины что-то валят в аппаратный стек, значит есть код, который это делает. Мне интересно на этот код посмотреть.
> Так ошибся ли ? Или просто ты не понял что к чему
> ?
> *подмигивание* А ведь ты так и не доказал не_использования стека для хранения
> локальных переменных или ссылок на них.. даже не просто не доказал,
> но и сделал вид что этого нет..
Это называется -- переложить бремя доказательства на оппонента. Приём демагогии такой. Мне не требуется что-либо опровергать, поскольку исходное твоё утверждение голословно. Тем не менее, скажу по секрету. Пример, на который я выше дал ссылку (2й фрагмент), как раз это и делает. Но к вопросу отношения не имеет. И я не знаю, как бы его к нему прикрутить.
>[оверквотинг удален]
> int testFunc( int arg ) {
> int tmp1 = 123;
> int tmp2 = 456;
> return tmp1 * arg;
> }
> push rbp
> mov rbp, rsp
>> Нет никаких [esp-n] при обращении к _аргументам_ вызываемой подпрограммы
> // ой, что это, ОТРИЦАТЕЛЬНОЕ смещение стека ? И по нему ЗАТАЛКИВАЕТСЯ
> аргумент ?)
Это называется - пролог функции и формирование стекового кадра. Поскольку указатель стека в теле функции меняется, проще адресовать стек через регистр базы стека. При этом значение ebp сохраняется (по конвенции оно неизменно для вызывающей стороны). В прошлом веке компиляторы так делали, поскольку были далеки от совершенства. Ныне это бессмысленная операция, если не считать упрощения отладки.
> mov dword ptr [rbp - 4], edi
> // Еще отрицательные смещения !?? ) Но теперь это локальная переменная !?)
Да, это локальная переменная, потому и смещение -- отрицательное. В ней сохранён переданный через регистр edi аргумент.
> mov dword ptr [rbp - 8], 123
> // Ребяят, ну хватит уже!
> mov dword ptr [rbp - 12], 456
Действительно, хватит выдавать локальные переменные подпрограммы за её аргументы.
> mov eax, dword ptr [rbp - 8]
> // Ой, неужели это ОБРАЩЕНИЕ К АРГУМЕНТУ ВЫЗЫВАЕМОЙ ПОДПРОГРАММЫ ПОСРЕДСТВОМ [esp-n] ?))
Нет, это локальная переменная tmp1.
> imul eax, dword ptr [rbp - 4]
А вот здесь как раз и должна была быть попытка выдать желаемое за действительное, но автор в горячке перепутал строчки.
> pop rbp
> ret
Возьми за правило указывать ключи транслятора, когда публикуешь листинг. Это поможет тебе самому избежать ряд ошибок.
Вот как должен был выглядеть твой пример:
gcc arg.c -S -fverbose-asm -masm=intel -o arg.s
testFunc:
.LFB0:
.cfi_startproc
push rbp #
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
mov rbp, rsp #,
.cfi_def_cfa_register 6
mov DWORD PTR -20[rbp], edi # arg, arg
# arg.c:2: int tmp1 = 123;
mov DWORD PTR -8[rbp], 123 # tmp1,
# arg.c:3: int tmp2 = 456;
mov DWORD PTR -4[rbp], 456 # tmp2,
# arg.c:4: return tmp1 * arg;
mov eax, DWORD PTR -8[rbp] # tmp84, tmp1
imul eax, DWORD PTR -20[rbp] # _4, arg
# arg.c:5: }
pop rbp #
.cfi_def_cfa 7, 8
ret
И предпочти изучать код после оптимизатора, это поможет понять, как работает транслятор:
gcc arg.c -O2 -S -fverbose-asm -masm=intel -o arg.s
testFunc:
.LFB0:
.cfi_startproc
# arg.c:4: return tmp1 * arg;
imul eax, edi, 123 # tmp84, tmp85,
# arg.c:5: }
ret
>> Общесистемное соглашение о вызовах для Linux AMD64 (см. System V AMD64 ABI)
> Это все здорово кнчн, но что если аргументов будет больше чем регистров
> ?) -Ну это к слову о не_использовании стека.
Для этого в скобочках и написано, что надо посмотреть.
> Тем более, что мире существует далеко не только линух со своими соглашениями
Здесь Линукс является системой по умолчанию. Архитектуру процессора ты выбрал сам, я лишь её актуализировал.
> о вызовах( хотя и в 32-битном линуховом очень даже применялся стек
> )
Ну вот и посмотрел бы, как именно он применялся, вместо эффектных попыток продемонстрировать свою базу.
Пока получается в стиле "сделайте это за меня".
Вот так передаются параметры процессу (тут немного лишнего, но оставлю как есть):
_start:
; Допустим 1 аргумент - имя файла байт-кода.
mov rcx, [rsp] ; argc
cmp ecx, 2
jz .1arg
puts error_about
mov edi, -EINVAL
jmp sys_exit
.1arg: mov rdi, [rsp + 16] ; argv
mov [bytecode_filename], rdi
; Переменные окружения находятся через argc+1 (завершающий 0-й указатель)
; слов после argv (rsp + 8)
lea rdx, [rsp + 8 + (rcx + 1) * 8]
mov [environment_variables], rdx
> Но, да, в общем и целом на х86_64 передача аргументов стала получше
> Часто данные передаются через регистры, а что не влезло - через стек
> против cdecl и stdcall
> Хотя и есть некоторые нюансы и в вызовах и в хранени локальных
> переменных
Это всё не имеет отношения к вопросу смещения. Просто подумай как следует, что в каком порядке складывается на стек в случае stdcall и почему помимо retn есть вариант с аргументом retn 8. И всё поймёшь. Особенно про "аргументы извлекаться" когда "адрес возврата остаётся".
