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

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

M>>но такая фича чисторегистровой машины тормозит переключение тредов, поскольку приходится спасать весь пул регистров. в стековой, по регистру StackTop всегда видно сколько регистров занято и спасаются только занятые. то есть на стековой быстрее можно сделать переключение тредов и переключать их чаще.
C>Это мелочь. В современных процессорах с аппаратной многопоточностью просто хранят два (или более) регистровых файла. Тем более, что регистры занимают что-то всего порядка 256 байт даже с учётом SSE-регистров.
это дает эффект лишь в случае если тредов меньше, чем этих ваших файлов. что нереально в общем случае.


M>>по поводу плохой конвейризации стековой машины непонятно, поскольку она по сути регистровая, с некоей модификацией.
C>Нельзя по командам узнать какие данные для каких команд нужны. Точнее, можно — но это, фактически, требует перевода в регистровую форму. Спрашивается: и нафига городить тогда огород?
так она итак в регистровой соббсно. другую аппаратную форму представить сложно.
придумать просто один аккумулятор и потом из него спасать в память при росте стека? глупо.
значит будут косвенно адресумые регистры.

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

C>>Это мелочь. В современных процессорах с аппаратной многопоточностью просто хранят два (или более) регистровых файла. Тем более, что регистры занимают что-то всего порядка 256 байт даже с учётом SSE-регистров.
M>это дает эффект лишь в случае если тредов меньше, чем этих ваших файлов. что нереально в общем случае.
Это даёт эффект в любом случае, так как можно заниматься выполнением другого потока пока загружаются данные из памяти.

C>>Нельзя по командам узнать какие данные для каких команд нужны. Точнее, можно — но это, фактически, требует перевода в регистровую форму. Спрашивается: и нафига городить тогда огород?
M>так она итак в регистровой соббсно. другую аппаратную форму представить сложно.
В случае стековой машины — данные НЕ в регистровой форме. То что стек может хранится в быстрой памяти — не делает стековую машину регистровой.

M>придумать просто один аккумулятор и потом из него спасать в память при росте стека? глупо.
M>значит будут косвенно адресумые регистры.
Что значит "косвенно адресуемые регистры" в стековой машине??

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

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

M>Если у нас есть адресуемую быструю "регистровую" память (а так оно и есть в java/.net байткоде), то мы можем
M>а) реализовать в железе сложный декдер, который будет последовательность
M>load r1
M>load r2
M>add
M>save r3
M>декодировать в одну комманду
M>add r1, r2, r3
M>и выполнять её за 1 такт.
M>б) реализовать в процессоре простой декодер, который будет воспринимать эту последовательность как 4 комманды, и выполнять за 4 такта.
гм. очевидно что в стековом случае первые две команды (load) делаются паралельно. при минимальном уме некоего конвейера стековой машины.
выполнение же трехоперандной команды за такт — полагает довольно развитой проц.
мои претензии тут к тому, что стековая предполагается предельно тупой, а трехоперандная — очень умной.
очень сложно сравнивать такие архитектуры.

M>Под "более медленным исполнением" стековых комманд я имел в виду случай (б). Поскольку случай (a) нет смысла реализовывать — будет проще и дешевле реализовать регистровый процессор/набор комманд, который мы ещё и исполнить сможем быстрее (можно уложить тот-же по функциональности код в меньшее число комманд/тактов).
мне кажется, что конвейеризация, которая априори предполагается для регистровой машины, реализуема и для стековой. поскольку без конвейера вообще одна регистровая двухоперандная команда выполнялась бы по стадиям вроде
выборка->декодирование->операция->занесение в регистр приемник...
короче что-то типа того.

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

M>>придумать просто один аккумулятор и потом из него спасать в память при росте стека? глупо.
M>>значит будут косвенно адресумые регистры.
C>Что значит "косвенно адресуемые регистры" в стековой машине??

берете 32 регистра(stack), припаиваете к ним регистр ST(stacktop).
при инициализации проца обнуляете ST.
команда push x отображается во внутреннюю команду — mov x, stack[ST++] — то есть номер актуального регистра выбирается из регистра ST, то есть мы имеем косвенную "регистрово-регистровую" индексацию. где есть массив регистров, а индекс массива выбирается из регистра ST.
команда add например есть команда
add stack[ST--],stack[ST]
и так далее.
потом закрываете это крышкой и оно работает.

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

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

C>>>Это мелочь. В современных процессорах с аппаратной многопоточностью просто хранят два (или более) регистровых файла. Тем более, что регистры занимают что-то всего порядка 256 байт даже с учётом SSE-регистров.
M>>это дает эффект лишь в случае если тредов меньше, чем этих ваших файлов. что нереально в общем случае.
C>Это даёт эффект в любом случае, так как можно заниматься выполнением другого потока пока загружаются данные из памяти.
какого другого потока, если диспетчер тредов фактически прервал текущий тред, спасает его контекст, восстанавливает контекст другого и потом уже переключается на новый тред? другого потока нет.
ну если только выполняется паралельно или около того спасение текущего набора регистров и восстановление какого-то старого. каким-то особым образом.
но "другого потока" нет.
вроде.

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

M>какого другого потока, если диспетчер тредов фактически прервал текущий тред, спасает его контекст, восстанавливает контекст другого и потом уже переключается на новый тред? другого потока нет.
Есть.
В некоторых процессорах например в ниагаре выполняются сразу несколько потоков.
Например 8. И соответственно 8 регистровых файлов.
Процессор каждый так переключается на следующий готовый поток.
Если поток промазал мимо кеша то его будут просто пропускать пока данные не приедут.

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

M>гм. очевидно что в стековом случае первые две команды (load) делаются паралельно. при минимальном уме некоего конвейера стековой машины.

Я не понимаю твоих слов. Конвеер не выполняет две комманды параллельно. Конвеер это конвеер. Он выполняет несколько инструкций одновременно,
но не параллельно. Разные стадии исполнения инструкций выполняются одновременно, а не инструкции выполняются одновременно.
Меньше одного такта на инструкцию уйти не может.
"Минимальный ум" для объединения комманд — это слишком оптимистично. У нас же конвеер. Данные могут уже лежать в регистре, а могут ещё только
вычисляться коммандой, которая где-то впереди в конвеере. Если ты будешь ждать когда правильные данные лягут в регистр — то конвеер накроется
медным тазом.

M>выполнение же трехоперандной команды за такт — полагает довольно развитой проц.

Вот именно за счёт конвеера они и выполняются за 1 такт. За каждый такт заканчивается выполнение одной инструкции, хотя само выполнение инструкции занимает несколько тактов.

M>мои претензии тут к тому, что стековая предполагается предельно тупой, а трехоперандная — очень умной.
M>очень сложно сравнивать такие архитектуры.

Трёхоперандному процессору не надо быть шибко умным, чтоб выполнять инструкцию за такт (при наличии конвеера).
Он её просто выполняет.
А стековому процессору надо быть очень умным, чтоб объединить несколько инструкций в одну и потом выполнить её за такт. Иначе он выполняет каждую инструкцию за такт.

M>мне кажется, что конвейеризация, которая априори предполагается для регистровой машины, реализуема и для стековой. поскольку без конвейера вообще одна регистровая двухоперандная команда выполнялась бы по стадиям вроде

Конечно реализуема. Но в регистровой архитектуре одна комманда выполняет сразу 4 операции стековой. Декодеру стековой машины надо объединить эти 4 операции в одну. Он это может сделать, но тогда всего-лишь будет ничем не лучше регистровой, зато намного сложнее. Гораздо проще сделать это (объединение 4 операций в одну) во время компиляции. Софтовым компилятором, который может думать столько, сколько ему надо. Используя сложные алгоритмы, видя весь метод целиком. А на аппаратном уровне это сделать столь оптимально нельзя (слишком сложно, чтоб это имело смысл делать). Кстати, Transmeta делала именно что-то подобное — инструкции x86, или java или какие в неё загрузили — компилировала софтом в свои внутренние VLIW инструкции, фактически объединяя несколько инструкций, и выполняла потом эти несколько объединённых инструкций как одну. И аппаратный декодер Intel-овских процессоров фактически делает ту-же работу, объединяя несколько инструкций в одну, чтоб быстрее их исполнять.

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

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

M>>какого другого потока, если диспетчер тредов фактически прервал текущий тред, спасает его контекст, восстанавливает контекст другого и потом уже переключается на новый тред? другого потока нет.
WH>Есть.
WH>В некоторых процессорах например в ниагаре выполняются сразу несколько потоков.
WH>Например 8. И соответственно 8 регистровых файлов.
WH>Процессор каждый так переключается на следующий готовый поток.
WH>Если поток промазал мимо кеша то его будут просто пропускать пока данные не приедут.
блин, мы что обсуждаем-то? некую регистровую и некую стековую архитектуры.
а куда скатился разговор? берется тупая стековая машина, технологического уровня интел8080, против нее выставляется проц уровня dualcore, и производится сравнение.
смысл сравнения неясен уже вообще, поскольку результат очевиден.
короче, хватит уж выдвигать какие-то навороты(которые можно и в стековую машину вставить между прочим), против минималисткой стековой машины.
так не честно.

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

C>>Что значит "косвенно адресуемые регистры" в стековой машине??
M>берете 32 регистра(stack), припаиваете к ним регистр ST(stacktop).
M>при инициализации проца обнуляете ST.
Я прекрасно понимаю как можно косвенно адресовать регистры. На некоторых архитектурах они вообще в память отображаются. Мне непонятно причём тут стековая машина?

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

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

M>блин, мы что обсуждаем-то? некую регистровую и некую стековую архитектуры.
M>а куда скатился разговор? берется тупая стековая машина, технологического уровня интел8080, против нее выставляется проц уровня dualcore, и производится сравнение.
Смысл в том, что со стековой машиной ты в любом случае не сделаешь процессор уровня Intel Core2 Duo. По крайней мере, в ближайшие много лет.

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

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

M>>блин, мы что обсуждаем-то? некую регистровую и некую стековую архитектуры.
M>>а куда скатился разговор? берется тупая стековая машина, технологического уровня интел8080, против нее выставляется проц уровня dualcore, и производится сравнение.
C>Смысл в том, что со стековой машиной ты в любом случае не сделаешь процессор уровня Intel Core2 Duo. По крайней мере, в ближайшие много лет.
ни автор топика, похоже, ни и я, не собирались делать core dio, ни в плис, ни на коленке, царапая ножичком тянутый кремний. разговор шел о любительском проекте, на плис, компактном проце, потому треп о конвейерах, переключаемых файлах регистров и проч паралелелизме — лишь демонстрация неуместной интеллигентности.

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

C>>Смысл в том, что со стековой машиной ты в любом случае не сделаешь процессор уровня Intel Core2 Duo. По крайней мере, в ближайшие много лет.
M>ни автор топика, похоже, ни и я, не собирались делать core dio, ни в плис, ни на коленке, царапая ножичком тянутый кремний. разговор шел о любительском проекте, на плис, компактном проце, потому треп о конвейерах, переключаемых файлах регистров и проч паралелелизме — лишь демонстрация неуместной интеллигентности.
Посмотри в тему топика: "А стековые архитектуры процессоров — совсем умерли?". Автор задал вопрос — мы на него ответили.

C>Посмотри в тему топика: "А стековые архитектуры процессоров — совсем умерли?". Автор задал вопрос — мы на него ответили.

Я что-то так и не понял — совсем или не совсем Вроде даже примеры современных подобных разработок нашлись.

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

C>>Посмотри в тему топика: "А стековые архитектуры процессоров — совсем умерли?". Автор задал вопрос — мы на него ответили.
dmz>Я что-то так и не понял — совсем или не совсем Вроде даже примеры современных подобных разработок нашлись.
А так же объяснения почему они разработками и останутся.

C>А так же объяснения почему они разработками и останутся.

Ну образцы-то нашлись вполне коммерческие, естественно это микроконтроллеры или специализированные процессоры.

M>>>но такая фича чисторегистровой машины тормозит переключение тредов, поскольку приходится спасать весь пул регистров. в стековой, по регистру StackTop всегда видно сколько регистров занято и спасаются только занятые. то есть на стековой быстрее можно сделать переключение тредов и переключать их чаще.
C>>Это мелочь. В современных процессорах с аппаратной многопоточностью просто хранят два (или более) регистровых файла. Тем более, что регистры занимают что-то всего порядка 256 байт даже с учётом SSE-регистров.
M>это дает эффект лишь в случае если тредов меньше, чем этих ваших файлов. что нереально в общем случае.

Это даст эффект в случае частого переключения между небольшим количеством потоков выполнения, что встречается достаточно часто в общем случае.

M>>>по поводу плохой конвейризации стековой машины непонятно, поскольку она по сути регистровая, с некоей модификацией.
C>>Нельзя по командам узнать какие данные для каких команд нужны. Точнее, можно — но это, фактически, требует перевода в регистровую форму. Спрашивается: и нафига городить тогда огород?
M>так она итак в регистровой соббсно. другую аппаратную форму представить сложно.
M>придумать просто один аккумулятор и потом из него спасать в память при росте стека? глупо.
M>значит будут косвенно адресумые регистры.

Регистровая машина использует трехпортовый регистровый файл — два чтения и одна запись. Стековая может использовать двухпортовый и даже однопортовый — либо чтение, либо запись. Трехпортовая память делается дублированием двухпортовой: читаем операнды из разных половинок, пишем всегда в обе. В стековых архитектурах верх стека — от одного до трех-четырех регистров, — выносится в защёлки-триггера, причем возможно обращение к любому верхнему регистру.

Это что касается экономии площади.

Теперь про регистры.

Я приведу ещё одну ссылку на Купмана: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.2.4718

Там хорошо видно, чем отличается раздача ресурсов для стековой машины и для регистровой.

Чистая стековая машина ещё называется нуль-операндной, поскольку операнды для операций заданы неявно. Нет в ней регистров в явном виде, и все тут.

M>>>придумать просто один аккумулятор и потом из него спасать в память при росте стека? глупо.
M>>>значит будут косвенно адресумые регистры.
C>>Что значит "косвенно адресуемые регистры" в стековой машине??
M>берете 32 регистра(stack), припаиваете к ним регистр ST(stacktop).
M>при инициализации проца обнуляете ST.
M>команда push x отображается во внутреннюю команду — mov x, stack[ST++] — то есть номер актуального регистра выбирается из регистра ST, то есть мы имеем косвенную "регистрово-регистровую" индексацию. где есть массив регистров, а индекс массива выбирается из регистра ST.
M>команда add например есть команда
M>add stack[ST--],stack[ST]
M>и так далее.
M>потом закрываете это крышкой и оно работает.

Причём работает гарантировано хуже, чем могло бы. Площади занимает больше, тактов потребляет больше и тп.

Судя по всему, вы на все это смотрите с точки зрения программной реализации. А они, как я уже говорил, различаются существенными деталями.