> man operating_systems
Переход на страницу  1 2 3 4 5 [6] 7
Модераторы: Roman I Khimov, Wanderer, Dron
Автор Добавил
ossadchy
Среда 08.10.2008 23:23
ID пользователя #941
Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181
NightRadio написал(а) ...

Вообщем-то я и имел в виду ассоциацию ячеек с регистрами Подобным образом происходит у меня в языке Pixilang: есть большая табличка; первые 256 ячеек - общие регистры (причем первые потом могут отображаться на настоящие железные регистры); остальные ячейки - глобальные переменные.
А вообще, идея упаковки SDE зацепила.. Покопаю в этом направлении

В RISC машинах и 1024 регистра есть.. а еще есть такое понятие как регистровые окна... а вообще-то -- оно по большому счёту не надо, код надо представить в формате достаточно удобном для передачи по Сети и достаточно простом для компьютера, а регистры и т.д. -- на уровне компиляции.

Вообще-то сейчас представление -- второстепенно, сейчас надо сделать что-то стоящее и компилировать его можно в байткод JAVA, CIL, X86 ASM или просто интерпретировать исходник.... главное, ИМХО, И Д Е Я. Если она будет удачной -- можно идти дальше.

P.S. оверквотинга небыло?

[ Редактирование Среда 08.10.2008 23:24 ]
Наверх
Сайт
NightRadio
Четверг 09.10.2008 05:43
ID пользователя #1102
Зарегистрирован: Четверг 11.09.2008 14:48
Сообщений: 23
Ну для простых смертных - регистров совсем смешное количество... это я про ARM и x86. 256 просто укладывается в байт. Например, виртуальная архитектура MMIX как раз содержит 256 регистров. Но это все детали...
Преставление - почему второстепенно? Что-то стоящее - это о чем речь?
Наверх
Dron
Четверг 09.10.2008 09:08


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Например, виртуальная архитектура MMIX как раз содержит 256 регистров.

2NightRadio: откуда же 256??? по моим сведениям их 8.

А, блин... это ж не MMX, а MMIX, который придумал Кнут! дык там риск. риски всегда имеют больше регистров.

Про регистровые окна кстати всмомнил ossadchy, это типа более удобная форма ассоциирования регистров с памятью.

Количество регистров выбирается исходя из кодирования мнемоник. Если ты разрабатываешь байткод - это актуально, но для семантического представления цифра 256 не имеет никакого смысла.

Здесь главное переносимость и компактность представления программы.

2ossadchy: Можно конечно квотить поменьше. но в принципе и так не очень страшно.

PS: вообще каежтся мне что не регистры ни память вообще не нужны для интерпретируемого представления. Но конкретные мысли что-то не скалдываются

[ Редактирование Четверг 09.10.2008 09:13 ]

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

Андрей Валяев
Наверх
Сайт
grizlyk
Воскресенье 12.10.2008 06:29
ID пользователя #757
Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72
NightRadio написал(а) ...

И тем не менее вот вопрос про интерпретатор.
...
Вот что будет в стековом байт-коде:
...
Регистровый байт код действительно в чистом варианте с RISC командами даст более большой код и будет выполняться дольше.
...
А что, если ввести еще один тип байт-кода.
...
Всего три команды. И выполняются быстрее чем стековые.
Что скажете на это?
Мне лично трудно судить, т.к. я не понял цели и сути изучаемого в этой ветке предмета, но на счет регистров и стека могу вот что сказать:

Представьте, что у вас процессор хиленький, скажем 32 битный эмбеддед 200МГц. На этом процике стоит 32 битная системная шина 100МГц. Процик конвейерный и поддерживает удвоенную скорость передачи данных на этой шине (подшина данных 200МГц), т.е. теоретически он способен пробежать все свое адресное пространство (непрерывно от 0 до максимума) читая/записывая пакеты данных с системной шины на свой внутренней частоте - 200 МГц.

Пусть практически у вас 512 Мбайт конвейерной DDR памяти, которая передает в конвейерном режиме пакеты по 16 байт с удвоенной частотой тактирования шины - задержка передачи каждого 32 битного слова в пакете 0,5х0,5х0,5х0,5 по отношению к тактовой частоте системной шины (пакет передается за два такта этой частоты).

Это значит, что у вас тут 512 мегабайт регистрового ОЗУ с произвольной выборкой. А вы хотите без острой необходимости поработать через стек, гоняя данные из регистра в регистр .

Я привел, конечно, упрощенную модель, с взятыми от потолка цифрами, но это цифры реально существующей аппаратуры ценового сегмента low-end и эта модель отражает реальную тенденцию.

На самом деле, для такой системы теоретически сбойной является операция чтения - выборка из внезапного адреса, с кэш промахом.

При сбое выборка первого 32 битного слова первого пакета конвейере может происходить с значительной задержкой и последовательность выборки пакета станет, например, такой - (3*10)х0,5х0,5х0,5 по отношению к тактовой частоте системной шины 100МГц (пакет передается за 32 такта).

Если каждая выборка пакета будет сбойной, то эффективная тактовая частота передачи данных в этой системе в этом примере вместо удвоения скорости шины может упасть в 2 раза по отношению к ней, т.е. на 100МГц шине до 50 мегагерц, вместо реально доступных 200.

На самом же деле все хуже, из-за нескоординированности действий по доступу к памяти (простоев/конфликтов доступа) реальная эффективная тактовая частота передачи данных в этой системе может упасть до значения 1-10 мегагерц, вместо реально доступных 200.

Это падение производительности легко проверить на практике на тех x86 машинах, где можно отключить конвейер и кэш и если в тестах устранить влияние ускоренной обработки команд внутри новых процессоров, расширенной шины и т.д., которое отключить нельзя, то какой-нибудь 486 будет работать с точно такой же производительностью, как и классический 88 процессор в ХТ.

Но если вы скоординируете действия своей программы, ОС, процессора и чипсета, то таких промахов после старта программы вообще никогда не будет. Это требование касается вашей программы тоже, которая должна так обращаться к памяти, чтобы система знала что именно ей надо упреждающе кэшировать.

Упреждающе кэшировать можно, т.к. процессор склонен циклиться немного на тех данных, которые он уже зачитал, а запись в память отложена, т.е. пока процессор пишет в кэш, система может упреждающе обновить кэш для чтения, т.к. шина памяти свободна. Для этого нужно подобрать правильные значения параметров оборудования, чтобы скрыть от процессора сбои конвейера (исключить простой/конфликт) на внешней шине (например, увеличить частоту части системной шины на 50% и т.д.).

Весь этот большой текст имеет простой смысл - оптимизации абстрагированной от конкретной аппаратуры, вероятно, не существует.

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

поработать через стек Если это логический стек, т.е. реализация разборных функций компилятора, то почему бы и нет, в конце концов сейчас ценится инкрементальность компиляции, а не скорость компиляции пакетов, но если вы хотите транслировать этот логический стек в аппаратный, то это может быть плохо, например, архитектура IBM PC на x86 работает со стеком как минимум в 2 раз медленней, чем с регистрами.
Наверх
grizlyk
Воскресенье 12.10.2008 06:51
ID пользователя #757
Зарегистрирован: Понедельник 06.11.2006 22:42
Сообщений: 72
grizlyk написал(а) ...

Если каждая выборка пакета будет сбойной, то эффективная тактовая частота передачи данных в этой системе в этом примере вместо удвоения скорости шины может упасть в 2 раза по отношению к ней
Ну, "считарь" я еще тот, ошибся я, ведь данные передаются по 4 байта за раз, так что:
вместо удвоения скорости шины может упасть в 8 раз по отношению к ней, т.е. на 100МГц шине до 12,5 мегагерц, вместо реально доступных 200.
Вот, так правильно вроде, хотя я уже не уверен в точности деления и умножения на 2, хотя проверял такой рассчет на бумажке.

ЗЫ: я не понял на счет желательности редактирования. Если редактировать, то результат редактирования и сам факт его применения по почте не посылается, а может кто по почте читает форум?
Наверх
Dron
Воскресенье 12.10.2008 11:03


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
Это форум а не список рассылки. поэтому редактирование предпочтительнее повторного ответа.

Насчет платформы я тоже думаю что в виртуальной машине регистровая память и оперативная память ничем не отличаются друго от друга. Поскольку ВременнЫе расходы на доступ аналогичны в обоих случаях.

[ Редактирование Воскресенье 12.10.2008 11:04 ]

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

Андрей Валяев
Наверх
Сайт
ossadchy
Четверг 16.10.2008 23:33
ID пользователя #941
Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181
Дык как там прогресс у ТС?
Наверх
Сайт
ossadchy
Четверг 23.10.2008 00:13
ID пользователя #941
Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181
или никак или очень плотно работает
Наверх
Сайт
Dron
Четверг 23.10.2008 14:21


ID пользователя #13
Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651
А кто такой ТС?

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

Андрей Валяев
Наверх
Сайт
ossadchy
Пятница 24.10.2008 10:18
ID пользователя #941
Зарегистрирован: Среда 10.10.2007 22:55
Местонахождение: Украина, Николаевская обл., г. Первомайск
Сообщений: 181
Dron написал(а) ...

А кто такой ТС?

Топик Стартер(от англ. Topic Starter ) -- человек открывший тему, если по-русски(т.е. можно писать не ТС а ЧОТ ).
Наверх
Сайт
Переход на страницу  1 2 3 4 5 [6] 7  

Перейти:     Наверх

Транслировать сообщения этой темы: rss 0.92 Транслировать сообщения этой темы: rss 2.0 Транслировать сообщения этой темы: RDF
Powered by e107 Forum System

© OSRC.info, 2004-2010.
Авторские права на любые материалы, авторы которых явно указаны, принадлежат их авторам. По вопросам публикации таких материалов обращайтесь к авторам.
Авторские права на любые другие материалы принадлежат OSRC.info.
Сайт является помещением библиотеки. Копирование, сохранение на жестком диске или иной способ сохранения произведений осуществляются пользователями на свой риск.
При использовании материалов сайта ссылка на OSRC.info обязательна.