The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Фреймворк для написания защищённых драйверов для ядра Linux ..., opennews (?), 01-Сен-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


49. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  –3 +/
Сообщение от n80 (?), 01-Сен-19, 12:34 
> учитывая, что ядро Линукса написано на СИ, кстати ядра виндов и маков на чем написаны ?

Строго говоря, не от хорошей жизни они на C написаны.

> зачем нужно "это", если давно уже есть и активно используется СИ ?

Ещё бы стандарт у C развивался /хотя бы/ со скоростью стандарта плюсов (казалось бы, куда уж медленнее, но нет). Имеющееся положение дел у C очень огорчает, но переходить на плюсы или что-то с ещё более требовательным рантаймом как-то совсем не хочется.

> Что может "это", что НЕ может СИ ?

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

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

55. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  –1 +/
Сообщение от Anonymoustus (ok), 01-Сен-19, 12:40 
> Строго говоря, не от хорошей жизни они на C написаны.

Вот это новости! На чём же они должны быть написаны?


> Ещё бы стандарт у C развивался /хотя бы/ со скоростью стандарта плюсов (казалось бы, куда уж медленнее, но нет). Имеющееся положение дел у C очень огорчает, но переходить на плюсы или что-то с ещё более требовательным рантаймом как-то совсем не хочется.

Назови-ка с аргументами, чего тебе не хватет в C89/90.


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

Вот и выросло поколение, не знающее историю Сишечки.

Ответить | Правка | Наверх | Cообщить модератору

69. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от n80 (?), 01-Сен-19, 13:39 
> Вот это новости! На чём же они должны быть написаны?

Ха, как будто на этот вопрос есть простой ответ. У всех имеющихся инструментов есть довольно крупные недостатки. Можно перечислить свойства, которыми должен обладать язык, но ни в одном они не сочетаются. Говорю же, не от хорошей жизни был сделан выбор, когда они начинались — выбора по факту и не было, а дальше уже тянут лямку legacy. Но это не значит, что нельзя иначе.

> Назови-ка с аргументами, чего тебе не хватает в C89/90.

Судя по выбору стандартов, автор поста — явный тролль, у которого на всё готовы аргументы в духе «это не нужно / это для неосиляторов / это можно сделать портянкой макросов или сторонними библиотеками / это ошибка, которую не заметит только скорбный разумом, внимательнее нужно быть / всегда так делали и это работает» и т.д. Я в курсе стандартных контраргументов по поводу фич того же C99, только вот тема слишком субъективная и холиварная, а мне это не упёрлось.

Некоторое из того, нехватка чего недавно в очередной раз всплывала: типизированные enum (нет, -fshort-enums или #define с приведением типа на каждую константу — не решение), возможность вывести известное на этапе компиляции (но не очень известное кодеру) число в сообщении static_assert без извращений (всего-то нужно было понять, какого размера структура получилась вместо ожидаемого, обычно это делают через скрипты и autotools или через совсем уж негуманные хаки на макросах, но это реально отвратительный путь для такого простого действия), возможность объявить union из структуры (саму структуру объявлять прямо внутри union, а не отдельно) и массива байтов / uint16_t для чтения содержимого структуры (так, чтобы при этом чтобы не было нужно указывать размер этого массива, а он вычислялся исходя из размера структуры, т.е. typedef union { struct { ... }; uint8_t bytes[]; } some_type_t;, а ещё чтобы использование такого объявления не было UB, если заранее известна целевая архитектура), возможность явным образом разрешить/запретить компилятору переставлять поля конкретных типов структур (а не только вставлять выравнивания) и вообще выкидывать те, которые в конкретном варианте сборки не используются или всегда константны.

> Вот и выросло поколение, не знающее историю Сишечки.

Мал^WМолодой человек, а ты готов эту клевету подтвердить аргументами (чего именно из истории C и его предшественников я упустил и как это может помочь делу) или кроме отсылки к возрасту, как водится, аргументов нет? Конкретику, конкретику в студию.

На всякий случай, уточню: я не топлю за rust, но того уровня статического анализа, который даёт -Wall -Wextra -Werror -Wnarrowing -Wwrite-strings -Wcast-qual (и ещё немного флагов) мне мало. А более продвинутому статическому анализу некоторые вещи в стандарте C, скажем так, не помогают.

Зачем я серьёзно отвечаю троллю, косящему под олда — вопрос, конечно, интересный. "В интернете кто-то не прав.pcx", мда.

Ответить | Правка | Наверх | Cообщить модератору

76. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +1 +/
Сообщение от JL2001 (ok), 01-Сен-19, 14:20 
> Зачем я серьёзно отвечаю троллю, косящему под олда — вопрос, конечно, интересный.

хороший серьёзный ответ прочтут и другие

Ответить | Правка | Наверх | Cообщить модератору

79. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Anonymoustus (ok), 01-Сен-19, 14:23 
>> Вот это новости! На чём же они должны быть написаны?
> Ха, как будто на этот вопрос есть простой ответ. У всех имеющихся
> инструментов есть довольно крупные недостатки. Можно перечислить свойства, которыми должен
> обладать язык, но ни в одном они не сочетаются. Говорю же,
> не от хорошей жизни был сделан выбор, когда они начинались —
> выбора по факту и не было, а дальше уже тянут лямку
> legacy. Но это не значит, что нельзя иначе.

На этот вопрос есть ответ и он давно дан в написанном ПО. Выбор для написания системного ПО всегда стоял и стоит между непереносимыми ассемблерами или переносимыми языками. Си был условно низкоуровневым _переносимым_ языком. Выбор был очевиден для всех тогда и таковым остаётся доныне. Legacy тут совершенно ни при чём. Си даёт квалифицированному программисту возможности, которых не дают, например, Паскаль или Фортран при написании системного ПО. Удивительно, что приходится объяснять столь банальные и общеизвестные вещи на как бы айтишном форуме.

Так от какой такой «не от хорошей жизни»? С конкретикой, пожалуйста.

У Си, впрочем, есть очень серьёзный недостаток: Си требует развитых мозгов и поэтому совершенно не подходит обезьянам.


>> Назови-ка с аргументами, чего тебе не хватает в C89/90.
> Судя по выбору стандартов, автор поста — явный тролль, у которого на
> всё готовы аргументы в духе «это не нужно / это для
> неосиляторов / это можно сделать портянкой макросов или сторонними библиотеками /
> это ошибка, которую не заметит только скорбный разумом, внимательнее нужно быть
> / всегда так делали и это работает» и т.д. Я в
> курсе стандартных контраргументов по поводу фич того же C99, только вот
> тема слишком субъективная и холиварная, а мне это не упёрлось.

Автор просто в курсе, что большинство жалобщиков не смогут объяснить даже себе различий между стандартами, ибо тех стандартов никогда не читали, но плачут о недостатке прогресса развития инноваций. Жалобщикам постоянно чего-то не хватает: то прямых рук, то мозгов, то денег. И постоянно что-то мешает: то ноги, то legacy, то «морально устаревшие» языки программирования, то другие люди.


> На всякий случай, уточню: я не топлю за rust, но того уровня
> статического анализа, который даёт -Wall -Wextra -Werror -Wnarrowing -Wwrite-strings
> -Wcast-qual (и ещё немного флагов) мне мало. А более продвинутому статическому
> анализу некоторые вещи в стандарте C, скажем так, не помогают.

А мне показалось, что ты как раз чуть ли не за деньги тут рекламируешь обезьянохруст, противопоставляя его сишечке. Почему не С++, почему не Objective-C, почему не D наконец? А, анон? Чем тебе так приглянулся недоязык с уродливым дегенеративным синтаксисом, созданный в берлоге браузерных макак и продвигаемый, как ни странно, обос**вшимся по уши производителем процессоров?


> косящему под олда

Вот так одной фразой и палится школота.

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

83. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Forthemail (ok), 01-Сен-19, 14:38 
Фортран да, не годится.
А что мешает на паскале писать системное ПО?
Не могу вспомнить примера, когда на C будет заведомо проще и удобнее писать.
Ответить | Правка | Наверх | Cообщить модератору

87. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Anonymoustus (ok), 01-Сен-19, 14:44 
Да ничего, в принципе, не мешает, просто сейчас не модно. А Яблоки же таки писали на своём варианте.

Но есть всё же обоснованные мнения против, пусть и относящиеся к старым версиям языка:

https://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Fav...

Да и сам Вирт для создания ПО предлагает всё-таки другие языки. Не вижу оснований сомневаться в компетентности Вирта. :)

Ответить | Правка | Наверх | Cообщить модератору

108. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от n80 (?), 01-Сен-19, 15:54 
> На этот вопрос есть ответ и он давно дан в написанном ПО.
> Выбор для написания системного ПО всегда стоял и стоит между непереносимыми
> ассемблерами или переносимыми языками. Си был условно низкоуровневым _переносимым_ языком.
> Выбор был очевиден для всех тогда и таковым остаётся доныне. Legacy
> тут совершенно ни при чём. Си даёт квалифицированному программисту возможности, которых
> не дают, например, Паскаль или Фортран при написании системного ПО. Удивительно,
> что приходится объяснять столь банальные и общеизвестные вещи на как бы айтишном форуме.

А тут кто-то спорил с тем, что он даёт возможности? Я лишь говорю про возможности, которых в C очень не хватает.

> Так от какой такой «не от хорошей жизни»? С конкретикой, пожалуйста.

Сам же выше и перечислил. Асм не переносим (не говоря уж про то что код получается либо читабельным, либо оптимизированным, либо крайне тяжёлым в поддержке, если не подходить по принципу "время студентов ничего не стоит, пусть и в машкоды руками транслируют"), фортран (при всех его плюсах, одни лишь модули вместо пары из заголовочных файлов и объектников/исходников мне греют душу невыразимо, что бы там фанаты разделения объявления и реализации не говорили) не подходит, ибо лишён многих нужных фич (ну не предполагалось его использовать для этого вообще), у паскаля были хуже компиляторы и тоже фич не хватает (а Модула-2 опоздала, да и не сказать, что сильно лучше Си), остальные языки или уже отмерли (и были такие, что не жалко), или ещё не появились (в смысле наличия библиотек и хорошего оптимизирующего компилятора, а не только ранних спецификаций).

> У Си, впрочем, есть очень серьёзный недостаток: Си требует развитых мозгов и
> поэтому совершенно не подходит обезьянам.

И зачем здесь эта очередная хлипкая попытка самоутверждения?
А потом он удивляется, почему его посты к срачам приводят, хотя всего-то стоит подавлять в себе эти абсолютно неинформативные вставки, не добавляющие по сути ровно ничего, кроме попыток автора возвыситься над «сирыми и убогими». Не надо возвышаться, факты надо.

> Автор просто в курсе, что большинство жалобщиков не смогут объяснить даже себе
> различий между стандартами, ибо тех стандартов никогда не читали, но плачут
> о недостатке прогресса развития инноваций. Жалобщикам постоянно чего-то не хватает: то
> прямых рук, то мозгов, то денег. И постоянно что-то мешает: то
> ноги, то legacy, то «морально устаревшие» языки программирования, то другие люди.

Разницу между стандартами я знаю в достаточной мере, чтобы заниматься дополнительным ручным трудом только в случае, когда это действительно необходимо (т.е. когда под целевую платформу компилятора нормального нет и не будет), а не тупо везде по принципу «ну ничего страшного же». И как по мне, предлагать что-то старше С99 могут либо бедолашные (кто по каким-то причинам очень ограничен в выборе компилятора), либо откровенно лютые ретрограды, которые отрицают stdint.h (а мне потом за ними чистить код, написанный в предположениях вида sizeof(int) == 2 и тому подобных) и считают необходимым заводить переменные строго в начале функции, а не минимизировать их область видимости (хотя это и холиварный тезис, но чем меньше контекст, тем проще код анализировать мозгами, и это нужно, не потому что мозги маленькие, а потому что если где-то можно накосячить, то рано или поздно накосячено будет и нужно минимизировать такие возможности by-design, а заодно не добавлять лишних сложностей для поиска косяков) и заводить разные переменные для разных нужд (которые компилятор всё равно сольёт в одну область памяти, если так можно), а не делать эту работу за компилятор (добавляя нелепые ошибки при этом, конечно же). Уже ради этих двух вещей нужен C99 (ими дело не ограничивается, но я про достаточный критерий). А если нужны атомарные операции, потоки (системное программирование ядром не ограничивается), static_assert и прочие мелкие радости — уже C11 нужен. Только вот мой тезис в том, что останавливаться на этом не нужно. Понятно, что можно закат Солнца вручную организовывать, только вот зачем, разве что ради сомнительного самоутверждения (путь школоты, которая не по возрасту, а по строению души) и job security.

> А мне показалось, что ты как раз чуть ли не за деньги
> тут рекламируешь обезьянохруст, противопоставляя его сишечке. Почему не С++, почему не
> Objective-C, почему не D наконец? А, анон? Чем тебе так приглянулся
> недоязык с уродливым дегенеративным синтаксисом, созданный в берлоге браузерных макак
> и продвигаемый, как ни странно, обос**вшимся по уши производителем процессоров?

Что-что? Где это я такой тезис толкал? Наоборот, про синтаксис (и вообще читабельность) один из моих первых постов в этой теме был. Как и в случае не к ночи помянутого systemd, я вижу определённый смысл в том направлении (в самом направлении, подчёркиваю), в котором они работают, но конкретная реализация меня очень не устраивает. Но работать-то нужно. Рано Сишечке останавливаться на достигнутом.

>> косящему под олда
> Вот так одной фразой и палится школота.

Если что-то можно сказать лаконично и доходчиво, на наиболее понятном для оппонента языке, — не вижу причин этого не делать, меня это школотой не делает, возможно, даже напротив: показывает что ещё не совсем мозги одеревенели (впрочем, с моей работой это вряд ли грозит).

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

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

159. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Anonymoustus (ok), 02-Сен-19, 06:50 
> В среде зрелых персонажей это лишнее.

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

Ответить | Правка | Наверх | Cообщить модератору

153. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +1 +/
Сообщение от Аноним (152), 02-Сен-19, 04:12 
Я тоже добавлю, хоть вопрос и не мне.

>Вот это новости! На чём же они должны быть написаны?

На паскале, на модуле, на обероне, да хотя бы на плюсах.

>Назови-ка с аргументами, чего тебе не хватет в C89/90.

Не слишком ли жирный? Или серьезно? В антиквариате даже машиннонезависимых типов нет. Нитей нет. Моделей памяти нет. И это "системный" язык! На этом вообще нельзя писать без гамака, весь код сразу же становится непереносимым, все нужно обмазывать макросами и ассемблером. Ах да, для прикладного программирования тоже не подходит - вместо строковой библиотеки какой-то ад. Ну, может хоть байтовые трюки можно попробовать, язык же для этого? А нет. Тут не кастуй, это UB. Знаковое переполнение - UB. Битовые поля - UB. Сдвиги - UB. Битовые хаки снабжены таким количеством UB, что нужно 10 лет опыта чтобы примерно понимать что не делать, ессно компилятор ничего не скажет - все развалится когда нибудь само. Поддержки такой стандартной концепции как атомик - нет (а в "современном" С11 нет векторов). Может быть, метапрограммирование хорошо реализовано? Нет, препроцессор убогий. Вот и получается, что язык-то - говно.

Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

156. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Anonymoustus (ok), 02-Сен-19, 06:39 
> Я тоже добавлю, хоть вопрос и не мне.
>>Вот это новости! На чём же они должны быть написаны?
> На паскале, на модуле, на обероне, да хотя бы на плюсах.

В этом вашем ИТ не ценятся интеллектуальные изобретения, потому что надо продавать инновационные прогрессивные новинки, а значит для программирования нужны не учёные, а индусы и умственно равные им эмигранты.


>>Назови-ка с аргументами, чего тебе не хватет в C89/90.
> Не слишком ли жирный? Или серьезно? В антиквариате даже // дальше поскипано

Нет, в самый раз, причём жир натуральный, а не пальмовый.

Антиквариат, напоминаю повторно, был написан для системы команд PDP. Антиквариат отражает собой _эту_ архитектуру. Он не предназначался для написания программ для x86, которой вообще не было во дни его создания. Сишечку, наверное, не стоило бы преподавать и учить для работы на иных архитектурах, и такое мнение нередко высказывают, но так уж сложилось, что антиквариат востребован повсюду. Однако регулярно находятся дурачки, повторяющие мантру про Си как ассемблер. Это какой-то позор. Да, для PDP Си действительно был заменителем ассемблера, но для x86 таковым не является. Открываешь любой толковый учебник по ассемблеру штеудовского хлама и начинаешь прозревать, как всё на самом деле плохо в этом вашем винтеловском ИТ, сколько внутри паутины, костылей, подпорок и распорок. Но кто ж нынче читает те учебники… Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.

А я недавно начал изучать малоизвестный среди опеннетовских аналитиков D. Не могу нарадоваться — так хорош этот язык. Уже написал несколько хеллоуворлдов и не останавливаюсь на достигнутом.

Ответить | Правка | Наверх | Cообщить модератору

171. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Совершенно другой аноним (?), 02-Сен-19, 10:01 
>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.

Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64. PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального), а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.), плюс доп. регистры (r8 - r15), ну и что SSE теперь должно быть обязательно, возможно и ещё, что-то по мелочи, что так на вскидку не вспомнилось.

Ответить | Правка | Наверх | Cообщить модератору

174. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Anonymoustus (ok), 02-Сен-19, 10:37 
>>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.
> Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64.
> PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального),
> а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х
> битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.),
> плюс доп. регистры (r8 - r15), ну и что SSE теперь
> должно быть обязательно, возможно и ещё, что-то по мелочи, что так
> на вскидку не вспомнилось.

Не другое. То же самое. И в соответствующих документах это прямо написано (AMD64 без PAE не работает). Отличия сугубо косметические.

Можете сказать без обращения к документации, сколько вам и вашим программам доступно для самостоятельной адресации на самом деле? Если помните, как устроена виртуальная память в x86. Уверен, что многих поклонников жирных регистров и 64-битного светлого будущего ждёт большой сюрприз.

Ответить | Правка | Наверх | Cообщить модератору

178. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Совершенно другой аноним (?), 02-Сен-19, 10:44 
>>>> Даже про одинаковую сущность PAE и AMD64 не знают и не понимают, а проповедуют прогрессивность уродца.
>> Всё-же PAE, которая (Physical Address Extension) это немного другое, поменьше, чем AMD64.
>> PAE это до 36-ти битов физического адресного пространства (32-х битах виртуального),
>> а AMD64 - по-моему это уже 40+ битов физического адресного пространства(64-х
>> битах виртуального), плюс расширение регистров до 64-х бит (rax и т.д.),
>> плюс доп. регистры (r8 - r15), ну и что SSE теперь
>> должно быть обязательно, возможно и ещё, что-то по мелочи, что так
>> на вскидку не вспомнилось.
> Не другое. То же самое. И в соответствующих документах это прямо написано
> (AMD64 без PAE не работает). Отличия сугубо косметические.

У нас используется PAE, и PSE36 в самописных системах без 64-х битного режима - т.е. 32-х разрядный защищённый режим - есть, PAE - есть, правда только из-за NX-бита, а вот 64-х разрядности - нету. То, что оно входит в AMD64 в качестве требований, как и тот-же SSE, не означает, что это одно и тоже.

> Можете сказать без обращения к документации, сколько вам и вашим программам доступно
> для самостоятельной адресации на самом деле? Если помните, как устроена виртуальная
> память в x86. Уверен, что многих поклонников жирных регистров и 64-битного
> светлого будущего ждёт большой сюрприз.

В 32-х битном режиме доступно 4G виртуального адресного пространства. Которые обычно разделяются на две части - ядерную и прикладную, как вариант по 2G каждая, ну или можно сделать и 1G/3G и, на самом деле любое другое.

Ответить | Правка | Наверх | Cообщить модератору

180. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Anonymoustus (ok), 02-Сен-19, 11:07 
Не хочу тратить своё время на бессмысленные споры. Берите документацию «первооткрывателей» и читайте, она написана очень ясным языком и занимает немногим более тысячи страниц. У Штеуда мануалы  на эту тему потолще будут.


AMD64 Architecture Programmer’s Manual


Volume 1: Application Programming

https://www.amd.com/system/files/TechDocs/24592.pdf


Volume 2: System Programming

https://www.amd.com/system/files/TechDocs/24593.pdf

Ответить | Правка | Наверх | Cообщить модератору

182. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +/
Сообщение от Anonymoustus (ok), 02-Сен-19, 11:09 
> В 32-х битном режиме доступно 4G виртуального адресного пространства. Которые обычно разделяются
> на две части - ядерную и прикладную, как вариант по 2G
> каждая, ну или можно сделать и 1G/3G и, на самом деле
> любое другое.

Я не про это, а про доступ к регистрам.

Ответить | Правка | К родителю #178 | Наверх | Cообщить модератору

190. "Фреймворк для написания защищённых драйверов для ядра Linux ..."  +1 +/
Сообщение от Совершенно другой аноним (?), 02-Сен-19, 11:49 
Прошу прощения, всё-же не понял, про что Вы. У нас, в самописной системе используется PAE, при этом все регистры 32-х разрядные (eax и т.д) - сам процессор 64-х разрядность (в виде AMD64) не поддерживает.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру