Результаты, аналогичные сопрограммам, можно получить и чисто вручную -- но да, придётся самому выделять блок памяти, хранить в нём всё, что нужно для возобновления выполнения, и т.д. и т.п. Т.е. это тоже неудобно, но контекст здесь роли не играет -- он реально не нужен: увидел, что не можешь продолжать работу до наступления некоего события -- сохрани нужные данные в динамически полученной области, передай её адрес той подпрограмме, которая. в конечном итоге, отвечает за возобновление выполнения после наступления ожидаемого условия, а после этого верни управление вызвавшей тебя программе. Собственно, сопрограммы именно это и делают.
Без динамических -- нельзя, но можно ж написать свои подпрограммы для выделения/освобождения памяти, и тогда компилятор будет дёргать их, а не свои стандартные. Соответственно, сие можно прилично оптимизировать.
Можно и точно -- я, собственно, именно о точном говорил, -- но это настолько извращённо и медленно будет, что чисто программно считать будет быстрей. Но таки да, один double в два float не укладывается, поскольку ширина мантиссы у double больше, чем у двух float.
Не получится. Если нет железной поддержки 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-х не ограничивается указанными машинами -- были и с кэшами, и конвейерные, и даже суперскалярные, где все эти проблемы были уже актуальны.
Грязные хаки, как понимаю?
Дык Вы ж написали и даже фотку приложили :) (вот если б ещё и совершенно секретное техническое описание...)
Результаты, аналогичные сопрограммам, можно получить и чисто вручную -- но да, придётся самому выделять блок памяти, хранить в нём всё, что нужно для возобновления выполнения, и т.д. и т.п. Т.е. это тоже неудобно, но контекст здесь роли не играет -- он реально не нужен: увидел, что не можешь продолжать работу до наступления некоего события -- сохрани нужные данные в динамически полученной области, передай её адрес той подпрограмме, которая. в конечном итоге, отвечает за возобновление выполнения после наступления ожидаемого условия, а после этого верни управление вызвавшей тебя программе. Собственно, сопрограммы именно это и делают.
Ну, если на то пошло, всё, начиная с ассемблера, -- синтаксический сахар...
Без динамических -- нельзя, но можно ж написать свои подпрограммы для выделения/освобождения памяти, и тогда компилятор будет дёргать их, а не свои стандартные. Соответственно, сие можно прилично оптимизировать.
Зря, что ли, он в своё время работал на совершенно секретных ЭВМ?
"Слева" и "справа" для первой фотки перепутаны.
Можно и точно -- я, собственно, именно о точном говорил, -- но это настолько извращённо и медленно будет, что чисто программно считать будет быстрей. Но таки да, один double в два float не укладывается, поскольку ширина мантиссы у double больше, чем у двух float.
Не получится. Если нет железной поддержки 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-х не ограничивается указанными машинами -- были и с кэшами, и конвейерные, и даже суперскалярные, где все эти проблемы были уже актуальны.