Не получится. Если нет железной поддержки 64-разрядных вещественных, их придётся считать чисто программно, используя целые числа.
Ну, если совсем формально, то можно поизвращаться и, используя 32-разрядные вещественные числа, отдельно считать "младшие половины" и "старшие половины" 64-разрядных вещественных чисел (в кавычках, поскольку, на самом деле, там всё сильно сложней будет), а потом их объединять, только там столько дополнительных целочисленных арифметико-логических операций потребуется, что быстрей уже всё считать с помощью одной только целочисленной арифметики, как это делают в ситуациях, когда процессор не поддерживает вещественную арифметику вообще. Но на графических процессорах с этим много хуже, чем на обычных -- они эффективны, когда над несколькими независимыми потоками данных можно выполнять идентичную последовательность операций, а в данном случае последовательность будет почти всегда индивидуальной (скажем, перед сложением/вычитанием надо сделать выравнивание порядков, и количество сдвигов при этом зависит от разности порядков складываемых/вычитаемых чисел).
В общем, если действительно нужен GPU с 64-разрядной вещественной арифметикой, то без вариантов: надо брать профессиональную железяку за 100500 денег.
AXI4 уменьшает сигнал ARLOCK до одного бита, чтобы учитывать только эксклюзивные передачи, поскольку заблокированные передачи не поддерживаются
Не заблокированные, а блокирующие, наверное -- т.е. захватывающие шины в монопольное владение на всё время выполнения операции.
Кроме того, secure лучше переводить как безопасный, а не защищённый. Защита -- это protection, она реализуется, например, средствами устройства защиты памяти (MPU, memory protection unit) на микроконтроллерах M- и R-профилей архитектуры ARM и используется операционной системой, чтобы защитить себя от прикладного кода, а прикладные задачи -- друг от друга. А secure -- это другое, к обычной защите памяти отношения не имеющее (есть некое "безопасное ПО", работающее независимо и над операционной системой, последняя точно так же не имеет доступа к безопасной памяти, как и прикладные программы; в общем, ещё один механизм защиты для борьбы с уязвимости в операционных системах).
Это как разведено. Поиск -- перебором комбинаций, записываемых в соответствующий регистр чипсета, и проверкой ответа (детали, естественно, уже не помню, но глянуть при нужде можно -- спецификации имеются).
Драйверы работать со всем этим и не должны: их дело -- управлять устройствами, а не настраивать их, последним занимаются BIOS и менеджер PnP из состава ОС (и драйверы шин -- но не драйверы устройств). Вот что далеко не всё было нормально реализовано -- да, но, повторюсь, это не жёсткое ограничение шины, а недостатки или прямые ошибки конкретных реализаций.
Кстати говоря, современная PCI-e с точки зрения программиста -- та же PCI, только немного расширенная, с сохранением совместимости "снизу вверх", хотя с точки зрения электроники -- совершенно другое.
Мосты PCI прозрачны для обычного обмена и никакого влияния на драйверы не оказывают. Они влияют только на процесс настройки, но технически никаких проблем "дотянуться" до удалённого устройства нет. Что в реализации раннего P&P было полно косяков -- это факт, но это именно косяки, а не какие-то принципиальные ограничения.
Что же до Unibus, то это чисто железная шина, без каких-либо программных ограничений (за исключением разрядности адреса и данных, понятное дело). Мастеров могло быть, в принципе, сколько угодно, хотя прерывания (точней, запросы на захват шины, в рамках которых выдавались в том числе и прерывания) мог обрабатывать только один арбитр шины (технически -- часть процессора, хотя логически -- независимая сущность). У нас, например, была СМ-1600 -- двухпроцессорная машина, где основной процессор реализовал систему команд PDP-11, а т.н. спецпроцессор -- систему команд М5000, только привилегированные были изменены. Идея там была в том, что ПДПшный проц рулит всем вводом-выводом, а спецпроцессор выполняет ОС и прикладные задачи, ранее созданные под М5000, а для ввода-вывода дёргает ПДПшный (через прерывание). Естественно, спецпроцессор тоже был мастером шины.
В стандартную PCI можно воткнуть много больше -- поскольку она не навязывает определённое распределение ресурсов и т.д. и т.п., ну а электрические ограничения преодолеваются с помощью мостов. А вот с эпловской шиной это не провернёшь -- как раз благодаря его недо-P&P.
Пы.Сы. ISA не менее прозрачная, да и более ранние шины тоже -- Unibus, например.
Это ущербный "P&P". Сие могло работать только на крайне убогой машине (Эпл-2 -- как раз такая, как и всё прочее 8-разрядное) с крайне убогим набором периферии (в природе существует 2,5 устройства, а сделать и воткнуть 25 в принципе невозможно -- ограничено количеством предусмотренных разъёмов, которое нельзя расширить -- в отличие от, например, ISA или PCI), где вся поддержка намертво зашита в ПЗУ и в "операционную систему" (нет возможности использовать сторонние устройства со сторонними драйверами). Для сколько-нибудь серьёзной техники это абсолютно недостаточно -- потому на ПК в конце концов P&P и сделали. А это... для меня -- ни разу не настоящий P&P.
Не было. То, что там было (я с этим знаком, хотя, в первую очередь, на наших Агатах, которые были полуклонами Эпла-2) -- это даже близко не P&P, это именно что вызов подпрограмм инициализации по фиксированному набору адресов из ПЗУ плат расширения, ежели таковые присутствовали. Абсолютно то же самое было реализовано (позже, да) в IBM PC, но никакого отношения к P&P это не имело.
P&P -- это, по меньшей мере, возможность стандартным образом определить наличие устройства, его тип и требуемый ему набор ресурсов, чтобы иметь возможность распределить их между имеющимися устройствами. Вызов же подпрограммы из ПЗУ более-менее решал только первую из этих задач.
На PDP-11/70, как и у процессора СМ-2420.01, кэш уже был. Кроме того, мир 1960-70-х не ограничивается указанными машинами -- были и с кэшами, и конвейерные, и даже суперскалярные, где все эти проблемы были уже актуальны.
Я как пример привёл: благодаря свободному стилю в Це++ я могу оформлять так, как мне нравится, и как больше соответствует конкретному случаю. Хотя для этого нужна, скажем так, самодисциплина и определённое чувство вкуса, что ли, иначе можно такое написать... :)
Был автоконфигуратор что в RSX-11, что в VAX/VMS, -- но он полагался на то, что устройства будут по стандартным адресам: обнаружил, что по некоему адресу что-то есть -- значит, это устройство такое-то, даже если там совсем другое устройство. Т.е. P&P в привычном современном виде, кажется, возникло всё-таки на ПК с программной поддержкой, в первую очередь, в Винде.
Но, за исключением P&P, я не знаю никаких "низкоуровневых" вещей, которые не использовались (пускай и в единичных случаях) уже в начале 1970-х.
А мне они не заходят :) Вообще, не люблю, когда язык навязывает стиль оформления. Хотя, есно, мой быдлокод (если он не на ассемблере, а на це/це++) с отступами и прочим, но иногда для улучшения читабельности оформляется довольно затейливо (скажем, длинное условие в if разбиваю на несколько строк, где тоже будут отступы).
Ну, разве что как технический термин. Типа, задержка -- это вообще про любую задержку, а латентность -- это сколько времени проходит от момента выдачи адреса в блок памяти до начала получения данных из этого блока. Хотя лично я предпочитаю использовать русский язык, если говорю/пишу на русском :)
Дохли только определенные схемы - это точно не "работала годами".
А это уж смотря где эти схемы используются. Скажем, в упоминавшейся СМ-1600 постоянно дохли упоминавшиеся К170-что-то-там в синхронном последовательном интерфейсе -- но машина сохраняла полную работоспособность и без этого интерфейса. А вот чтоб у неё вышел из строя процессор, память, контроллеры дисков или лент -- такого не припоминаю вообще (как и у всех СМок, с которыми был знаком). И они реально, за исключением отдельных периферийных устройств (в данном случае -- мало кому нужного интерфейса), годами сохраняли работоспособность без необходимости ремонта.
Я всегда стараюсь использовать русские, за исключением либо устоявшейся терминологии, либо когда не могу придумать достаточно короткого русского аналога. Грубо говоря, я буду писать "монитор" или "дисплей", а не "устройство видеоконтрольное", как в советской документации, но вот в своём переводе "Принципов работы Системы 370" и "...z/Architecture" я exception перевожу, как его перевели в СССР -- "особый случай", ибо слово "исключение" жутко перегружено ("за исключением исключения в связи с исключением".
Не получится. Если нет железной поддержки 64-разрядных вещественных, их придётся считать чисто программно, используя целые числа.
Ну, если совсем формально, то можно поизвращаться и, используя 32-разрядные вещественные числа, отдельно считать "младшие половины" и "старшие половины" 64-разрядных вещественных чисел (в кавычках, поскольку, на самом деле, там всё сильно сложней будет), а потом их объединять, только там столько дополнительных целочисленных арифметико-логических операций потребуется, что быстрей уже всё считать с помощью одной только целочисленной арифметики, как это делают в ситуациях, когда процессор не поддерживает вещественную арифметику вообще. Но на графических процессорах с этим много хуже, чем на обычных -- они эффективны, когда над несколькими независимыми потоками данных можно выполнять идентичную последовательность операций, а в данном случае последовательность будет почти всегда индивидуальной (скажем, перед сложением/вычитанием надо сделать выравнивание порядков, и количество сдвигов при этом зависит от разности порядков складываемых/вычитаемых чисел).
В общем, если действительно нужен GPU с 64-разрядной вещественной арифметикой, то без вариантов: надо брать профессиональную железяку за 100500 денег.
Про неё, а вот что перечёркнута -- не воспринял.
Вообще-то, 0,5 (дес) + 0,5 (дес) = 1,0 (дес), даже если они представлены в виде двоичных вещественных чисел.
Не заблокированные, а блокирующие, наверное -- т.е. захватывающие шины в монопольное владение на всё время выполнения операции.
Кроме того, secure лучше переводить как безопасный, а не защищённый. Защита -- это protection, она реализуется, например, средствами устройства защиты памяти (MPU, memory protection unit) на микроконтроллерах M- и R-профилей архитектуры ARM и используется операционной системой, чтобы защитить себя от прикладного кода, а прикладные задачи -- друг от друга. А secure -- это другое, к обычной защите памяти отношения не имеющее (есть некое "безопасное ПО", работающее независимо и над операционной системой, последняя точно так же не имеет доступа к безопасной памяти, как и прикладные программы; в общем, ещё один механизм защиты для борьбы с уязвимости в операционных системах).
Адблок пожирает. Я просто его отключил на этой странице, и всё.
Грибочков!
Это как разведено. Поиск -- перебором комбинаций, записываемых в соответствующий регистр чипсета, и проверкой ответа (детали, естественно, уже не помню, но глянуть при нужде можно -- спецификации имеются).
Драйверы работать со всем этим и не должны: их дело -- управлять устройствами, а не настраивать их, последним занимаются BIOS и менеджер PnP из состава ОС (и драйверы шин -- но не драйверы устройств). Вот что далеко не всё было нормально реализовано -- да, но, повторюсь, это не жёсткое ограничение шины, а недостатки или прямые ошибки конкретных реализаций.
Кстати говоря, современная PCI-e с точки зрения программиста -- та же PCI, только немного расширенная, с сохранением совместимости "снизу вверх", хотя с точки зрения электроники -- совершенно другое.
Мосты PCI прозрачны для обычного обмена и никакого влияния на драйверы не оказывают. Они влияют только на процесс настройки, но технически никаких проблем "дотянуться" до удалённого устройства нет. Что в реализации раннего P&P было полно косяков -- это факт, но это именно косяки, а не какие-то принципиальные ограничения.
Что же до Unibus, то это чисто железная шина, без каких-либо программных ограничений (за исключением разрядности адреса и данных, понятное дело). Мастеров могло быть, в принципе, сколько угодно, хотя прерывания (точней, запросы на захват шины, в рамках которых выдавались в том числе и прерывания) мог обрабатывать только один арбитр шины (технически -- часть процессора, хотя логически -- независимая сущность). У нас, например, была СМ-1600 -- двухпроцессорная машина, где основной процессор реализовал систему команд PDP-11, а т.н. спецпроцессор -- систему команд М5000, только привилегированные были изменены. Идея там была в том, что ПДПшный проц рулит всем вводом-выводом, а спецпроцессор выполняет ОС и прикладные задачи, ранее созданные под М5000, а для ввода-вывода дёргает ПДПшный (через прерывание). Естественно, спецпроцессор тоже был мастером шины.
В стандартную PCI можно воткнуть много больше -- поскольку она не навязывает определённое распределение ресурсов и т.д. и т.п., ну а электрические ограничения преодолеваются с помощью мостов. А вот с эпловской шиной это не провернёшь -- как раз благодаря его недо-P&P.
Пы.Сы. ISA не менее прозрачная, да и более ранние шины тоже -- Unibus, например.
Это ущербный "P&P". Сие могло работать только на крайне убогой машине (Эпл-2 -- как раз такая, как и всё прочее 8-разрядное) с крайне убогим набором периферии (в природе существует 2,5 устройства, а сделать и воткнуть 25 в принципе невозможно -- ограничено количеством предусмотренных разъёмов, которое нельзя расширить -- в отличие от, например, ISA или PCI), где вся поддержка намертво зашита в ПЗУ и в "операционную систему" (нет возможности использовать сторонние устройства со сторонними драйверами). Для сколько-нибудь серьёзной техники это абсолютно недостаточно -- потому на ПК в конце концов P&P и сделали. А это... для меня -- ни разу не настоящий P&P.
Не было. То, что там было (я с этим знаком, хотя, в первую очередь, на наших Агатах, которые были полуклонами Эпла-2) -- это даже близко не P&P, это именно что вызов подпрограмм инициализации по фиксированному набору адресов из ПЗУ плат расширения, ежели таковые присутствовали. Абсолютно то же самое было реализовано (позже, да) в IBM PC, но никакого отношения к P&P это не имело.
P&P -- это, по меньшей мере, возможность стандартным образом определить наличие устройства, его тип и требуемый ему набор ресурсов, чтобы иметь возможность распределить их между имеющимися устройствами. Вызов же подпрограммы из ПЗУ более-менее решал только первую из этих задач.
На PDP-11/70, как и у процессора СМ-2420.01, кэш уже был. Кроме того, мир 1960-70-х не ограничивается указанными машинами -- были и с кэшами, и конвейерные, и даже суперскалярные, где все эти проблемы были уже актуальны.
Я как пример привёл: благодаря свободному стилю в Це++ я могу оформлять так, как мне нравится, и как больше соответствует конкретному случаю. Хотя для этого нужна, скажем так, самодисциплина и определённое чувство вкуса, что ли, иначе можно такое написать... :)
Был автоконфигуратор что в RSX-11, что в VAX/VMS, -- но он полагался на то, что устройства будут по стандартным адресам: обнаружил, что по некоему адресу что-то есть -- значит, это устройство такое-то, даже если там совсем другое устройство. Т.е. P&P в привычном современном виде, кажется, возникло всё-таки на ПК с программной поддержкой, в первую очередь, в Винде.
Но, за исключением P&P, я не знаю никаких "низкоуровневых" вещей, которые не использовались (пускай и в единичных случаях) уже в начале 1970-х.
Скрытые резервы ещё есть -- пробелы, например. В Древнем Риме в этом толк знали :)
А мне они не заходят :) Вообще, не люблю, когда язык навязывает стиль оформления. Хотя, есно, мой быдлокод (если он не на ассемблере, а на це/це++) с отступами и прочим, но иногда для улучшения читабельности оформляется довольно затейливо (скажем, длинное условие в if разбиваю на несколько строк, где тоже будут отступы).
Ну, разве что как технический термин. Типа, задержка -- это вообще про любую задержку, а латентность -- это сколько времени проходит от момента выдачи адреса в блок памяти до начала получения данных из этого блока. Хотя лично я предпочитаю использовать русский язык, если говорю/пишу на русском :)
А это уж смотря где эти схемы используются. Скажем, в упоминавшейся СМ-1600 постоянно дохли упоминавшиеся К170-что-то-там в синхронном последовательном интерфейсе -- но машина сохраняла полную работоспособность и без этого интерфейса. А вот чтоб у неё вышел из строя процессор, память, контроллеры дисков или лент -- такого не припоминаю вообще (как и у всех СМок, с которыми был знаком). И они реально, за исключением отдельных периферийных устройств (в данном случае -- мало кому нужного интерфейса), годами сохраняли работоспособность без необходимости ремонта.
Plug & Play?
Я всегда стараюсь использовать русские, за исключением либо устоявшейся терминологии, либо когда не могу придумать достаточно короткого русского аналога. Грубо говоря, я буду писать "монитор" или "дисплей", а не "устройство видеоконтрольное", как в советской документации, но вот в своём переводе "Принципов работы Системы 370" и "...z/Architecture" я exception перевожу, как его перевели в СССР -- "особый случай", ибо слово "исключение" жутко перегружено ("за исключением исключения в связи с исключением".