У нас много чего применяли, только это не прижилось. Завод "Светлана" (у нас в Питере) выпускал полностью асинхронные процессоры (без сигнала тактирования), работали они по принципу запрос-ответ (ready/busy), но распространения эта идея не получила, т.к. процы были склонны к зависаниям, а проверить факт зависания было невозможно.Сообщение от Vladimir Kladov
Но вообще, создание проца с собственной архитектурой занятие полезное, т.к. можно вживую увидеть все достоинства и недостатки той или другой вычислительной архитектуры. Раньше (когда не было ПЛИС) это можно было сделать только на моделях (выпуск в железе могли себе позволить только крупные заводы), а теперь можно сделать и в железе.
какую таблицу... Нет никакой таблицы. Вот представьте - 4 байта по адресу 0000_0104H. И "под" ними - 4 байта дескриптора, по адресу 1_0000_0104H. На самом деле, теневая память с дескрипторами может адресоваться так, чтобы в SDRAM обе четверки попали в одну линейку. И может быть групповой дескриптор на 256 байт. И думаю, этого достаточно. Памяти - ровно в 2 раза больше надо. Зато программистам будет проще жить - сейчас этот ресурс дороже какой-то там памяти.
Где это взять, это в ПЦ есть? Как задействовать? Колись уже, а то у меня ситуация с прогой именно такая вышла - пришлось отложить проект и надолго (нет, не EmuZWin, с ним все в порядке, просто некогда).
Если про это:
Model-Specific Registers – модельно-специфические регистры.
Эти регистры предоставляют средства программной связи с микроархитектурой процессора, все важнейшие настройки которые можно менять программно находятся именно там.
...
Команды RDMSR и WRMSR
Команда RDMSR (ReaD from Model Specific Register) выполняет чтение из MSR-регистра. Действие команды заключается в проверке двух условий: во-первых, проверяется наличие нулевого уровня привилегированности кода, во-вторых, проверяется наличие в регистре ECX значения, адресующего один из MSR-регистров. Если хотя бы одно из этих условий не выполняется, то выполнение команды RDMSR заканчивается. Если выполняются оба условия, то значение MSR-регистра, адресуемого содержимым регистра ECX, помещается в пару 32-битных регистров EDX:EAX.
то это вряд ли поможет.
Ну - это дико не оптимально. Это примерно как Бил Гейтс везде продвигает свой бейсик и C# (хотя это дикие тормоза и огромный бесполезный расход памяти, в результате чего любой комп. работает со скоростью 386го). Вспомните алгоритмы из книг Кнута (там все было оптимально и написано на ассемблере).
Да есть во всех процах начиная с Pentium Pro (см. интеловскую доку по процу том 3)
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Для этого есть DevPartner Studio (раньше BoundsChecker).
Да, конечно, неоптимально. Хранить boolean в байте - тоже неоптимально. Знаете, что на самом деле НЕ ОПТИМАЛЬНО? Не оптимально - не иметь возможности найти максимум ошибок в программе до того, как она зависнет, и завесит систему. Не оптимально - заставлять программеров искать баги, которые могли бы себя проявит сами, и сказать - "вот тут ошибка". Не оптимально - пытаться сделать не-дырявую ось на дырявом по определению железе (см. проект Singularity).
эта платная штука. И пробовал я ее. Ничего она не может. В этой ситуации - ничего. Не знаю, где там ей что сказать надо, чтобы она указала, откуда ноги выросли. Да, забыл сказать: задача многопоточная (> 5 потоков), и вообще непонятно, в каком потоке вылет.
Для того чтобы работали все проверки надо компилить с ее библиотекой (для MSVC) старые версии поддерживали и делфи, был BoundChecker Delphi edition. При этом ловсятся ошибки с точностью до заданого числа байт. Технология очень простая, перед вызовом функции массивы и стек заполняются патерном, потом этот патерн проверяется, если были переполнения - это тутже выявляется.
Проблема как всегда не в железе, а в криворуких програмерах, какое хорошее железо не делай и там найдутся те кто напишет программу, которая будет работать с глюками на самом отказоустойчивом железе. Раньше люди программирвоали на асме и выявляли все ошибки, а сейчас не могут выявить ошибки на ЯВУ (хотя это на порядок проще).
В большинстве своем наличие трудноотлаживаемых ошибок в программе, обуславливается стилем программирвоания. Есть у меня одна отечетсвенная книга (годов еще 60х), называется "Индивидуальная отладка программ", там про это очень хорошо написано. Книга актуальна и в наше время.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
