Аннотация:
Расширение PCI ROM BIOS содержит программные компоненты, не входящие по разным причинам в системный BIOS. В статье рассмотрена методика разработки расширения PCI ROM BIOS, упрощающая процесс разработки и уменьшающая количество потенциальных ошибок. Предлагаемая методика актуальна как для PCI-устройств, так и для устройств PCI-Express, т.к. их программная модель конфигурации и расширения ROM BIOS совместима с программной моделью PCI-устройств.
Re: Программирование расширения ROM BIOS персонального компь
Вы меня извините, конечно, но я не понял для чего это статья сегодня? Почитав её я вспомнил себя в 80-х годах.
Когда сегодня человек пишет, что для каких-то целей ассемблер удобнее чем любой другой язык программирования высокого уровня, мне почему-то уже дальше читать не хочется и реноме автора резко устремляется к нулю.
Я как человек, пишущий embedded софт много лет для туевой хучи разного железа (не PC-совместимого), ответственно заявляю, что ассемблер использовать абсолютно НЕ НУЖНО.
Сегодня это означает не уважать в первую очередь себя, тратить на лишнюю мороку своё время и время возможных заказчиков. Ну, разве что для себя побалываться на досуге.
Нет более неудобного языка программирования чем ассемблер и нет более длительного процесса программирования чем на ассемблере (если только не сразу в машинных кодах писать ). Я уже лет 10, а то и все 15 как забыл что значит использовать ассемблер (ну его в топку). И безмерно рад, что на все новые железки обязательно (иначе железке не суждено стать покупаемой!) приложен хороший компилятор Си, Си++, чего раньше (в давние времена) приходилось дожидаться.
Так что желаю всем как следует научиться и использовать современные быстрые способы программирования, в т.ч. embedded.
Вот такое моё мнение...
Re[2]: Программирование расширения ROM BIOS персонального ко
Ну что, и такое мнение имеет право на существование. Мой ответ ни в коем случае не стоит восприниаать как попытку в чем-то убедить. К сожалению опыт показывает что каждому мила его личная КОЧКА зрения не зависимо от объективных обстоятельств. Теперь по делу.
Статья не про ассемблер, а про методику программирования расширения ROM BIOS персонального компьютера. И язык здесь не главное.
Каждую задачу нужно решать адекватным инстументом. Языком Си я владею гораздо лучше чем ASM'ом и пробывал его использовать для данной задачи. Написал быстро, а при отладке вышел полный облом, т.к. все компиляторы подразумевают наличие какой-либо операционки и, соответственно подключают библиотеки на нее рассчитанные, а расширениЕ ROM BIOS персонального компьютера РАБОТАЕТ КОГДА ОС НЕ ЗАГРУЖЕНА. К тому же программа на С для х86 разбухает больше чем имеющаяся ПЗУха. Так что ASM в данном случае более, чем адекватный инстумент. В общем еще раз поразмыслите над ОБЪЕКТИВНЫМИ (т.е. не зависимыми от личного отношения) ОБСТОЯТЕЛЬСТВАМИ решения данной задачи
П.С. физик Ландау как-то писал, что если прочитал работу и не понял, то перечитывай ее пока не поймешь (рецепт получения Нобелевской премии)
П.П.С. Как человек, пишущий embedded софт много лет для туевой хучи разного железа Вы должны знать, что существуют задачи, которые должны решаться в ЖЕСТКОМ РЕАЛЬНОМ ВРЕМЕНИ. А компиляторы Си, Си++ (тем более для х86) еще не настолько опимизированы, чтобы получить код ЭФФЕКТИВНЕЕ ПО ВРЕМЕНИ чем ASM. Так что как минимум вставки на ASM имеют право на жизнь. А то, что Вы не любите ASM, ну и что. Лекарство то же как правило не любят, однако ж пьют, потому, что иначе нельзя.
Кстати уточните что за туева хуча разного железа и что за задачи вы решаете и какое это реальное время, жесткое мягкое или все равно какое. Как говаривал известный персонал: "Я бывают разные.."
С уважением Сазонов Сергей
автор статьи "Программирование расширения ROM BIOS персонального компьютера"
Re[2]: Программирование расширения ROM BIOS персонального ко
D>Вот такое моё мнение...
Речь идет о программирования ROM BIOS где все пишется на ассемблере
До сих пор существует много приложений которые требует по крайней мере часть кода на ассемблере. Например PXE stuff. Или boot loader of BSP который как правило пишется на ассемблере.
Re: Программирование расширения ROM BIOS персонального компь
ССВ>Авторы: ССВ> Сазонов Сергей Валерьевич
ССВ>Аннотация: ССВ>Расширение PCI ROM BIOS содержит программные компоненты, не входящие по разным причинам в системный BIOS. В статье рассмотрена методика разработки расширения PCI ROM BIOS, упрощающая процесс разработки и уменьшающая количество потенциальных ошибок. Предлагаемая методика актуальна как для PCI-устройств, так и для устройств PCI-Express, т.к. их программная модель конфигурации и расширения ROM BIOS совместима с программной моделью PCI-устройств.
Большое спасибо за публикацию такой статьи. Очень интересная информация.
Вопрос к автору. Какие апаратные средства вы можете порекомендовать для отладки ? Я слышал что выбор очень небольшой и это железо стоит очень дорого. Но хотелось бы услышать ваше мнение.
Re[3]: Программирование расширения ROM BIOS персонального ко
Здравствуйте, eagersh, Вы писали: E>Речь идет о программирования ROM BIOS где все пишется на ассемблере E>До сих пор существует много приложений которые требует по крайней мере часть кода на ассемблере. Например PXE stuff. Или boot loader of BSP который как правило пишется на ассемблере.
А с чего вы взяли, что "как правило пишется на ассемблере"? Я вот почему-то очень сильно сомневаюсь, например, что современные бивисы пишутся на асме.
Re[2]: Программирование расширения ROM BIOS персонального ко
D> ответственно заявляю, что ассемблер использовать абсолютно НЕ НУЖНО.
Тут есть два случая.
1. Когда без ассемблера обойтись невозможно, например, потому что языки высокого уровня не обладают необходимыми средствами (скажем, инициализация защищенного режима на x86), либо если критически важно получить двоичный код минимального размера (BIOS, boot sectors и т.п.).
2. Когда крайне важна производительность. На сегодня остается очень мало случаев, когда программирование на ассемблере дает более эффективный код, чем сгенерированный хорошим компилятором. Но, например, в случае вычислений над векторами-матрицами иногда можно написать на ассемблере с использованием всяких SSE существенно более эффективный код, чем сгенерированный каким-либо компилятором. Но это, естественно, требует глубоких знаний архитектуры конкретного процессора.
Re[3]: Программирование расширения ROM BIOS персонального ко
Здравствуйте, Аноним, Вы писали:
А>Каждую задачу нужно решать адекватным инстументом. Языком Си я владею гораздо лучше чем ASM'ом и пробывал его использовать для данной задачи. Написал быстро, а при отладке вышел полный облом, т.к. все компиляторы подразумевают наличие какой-либо операционки и, соответственно подключают библиотеки на нее рассчитанные, а расширениЕ ROM BIOS персонального компьютера РАБОТАЕТ КОГДА ОС НЕ ЗАГРУЖЕНА. К тому же программа на С для х86 разбухает больше чем имеющаяся ПЗУха. Так что ASM в данном случае более, чем адекватный инстумент. В общем еще раз поразмыслите над ОБЪЕКТИВНЫМИ (т.е. не зависимыми от личного отношения) ОБСТОЯТЕЛЬСТВАМИ решения данной задачи
Я по поводу программирования железа мыслю уже более 20 лет (ну, забыл уже когда началось ). По поводу сказанного Вами выше, не буду сильно вдаваться в полемику. Скажу только, что Вам не мешало бы КАК СЛЕДУЕТ изучить инструмент под названием Си-компилятор (которым Вы пользуетесь) в части его опций и настроек. Про то, что компиляторы подразумевают наличие операционки и де подключают вне зависимости от Вашей воли какие-то библиотеки, я даже оставлю без комментария, это всё лишь подтверждает то что я сказал.
А>П.С. физик Ландау как-то писал, что если прочитал работу и не понял, то перечитывай ее пока не поймешь (рецепт получения Нобелевской премии)
Ну, мне то зачем это перечситывать? Неужели Вы думаете, что я что-то не понял?
А>П.П.С. Как человек, пишущий embedded софт много лет для туевой хучи разного железа Вы должны знать, что существуют задачи, которые должны решаться в ЖЕСТКОМ РЕАЛЬНОМ ВРЕМЕНИ. А компиляторы Си, Си++ (тем более для х86) еще не настолько опимизированы, чтобы получить код ЭФФЕКТИВНЕЕ ПО ВРЕМЕНИ чем ASM. Так что как минимум вставки на ASM имеют право на жизнь.
Сейчас нет, НЕ ИМЕЮТ. Объясняю. Сегодня железо столь стремительно развивается и столь стремительно падает в цене, что если Вам не хватает быстродействия одного железа, то Вы можете взять другое, более шустрое. Главное сегодня — БЫСТРО разработать железку и ЕЩЁ БЫСТРЕЕ написать для неё софт. Я весь свой embedded софт, который по определению считаю работающим в РЕАЛЬНОМ времени (иначе назначение железа непонятно), пишу ТОЛЬКО на Си-подобных компиляторах. Это обеспечивает БЫСТРОЕ написание кода, плюс вагон разных наработанных модулей (а это тоже УСКОРЯЕТ написание софта и во многом позволяет избегать повторных или новых ошибок), которые в случае АСМа (в отличие от Си) практически непереносимы на другое несовместимое железо. Грубый пример. Возьмём какой-нибудь контроллер за 2 бакса. По опыту я догадываюсь (ну, или иными расчётами), что его не хватает для моей задачи. Тогда я беру контроллер за 3 бакса, который вдвое шустрее. За день-два-три дня пишу на Си софт (ну, или неделю, если он "развесистый" сильно) и готово дело. В случае АСМа можно парить мозги месяц. Где экономнее? Ради одного бакса? Сколько Вы захотите за свою работу на АСМе? А заказчик какой вариант выберет? Нет, конечно, в случае миллионного тиража (а часто ли такое? ), может оказаться и один бакс выгодно сэкономить, но при издержках на всё остальное (у нас особенно) этот бакс "утонет" во этом всём остальном.
А>Кстати уточните что за туева хуча разного железа и что за задачи вы решаете и какое это реальное время, жесткое мягкое или все равно какое.
От различных контроллеров (51, АВР, АРМы и пр.) до ADSP от Texas и AD. Например, последнее дело — разрабатывал и программил гигабитный эзернет контроллер на Тайгер Шарке 201 от AD. Как раз этот контроллер обеспечивает приём инфы через линк-порт и выдачу в эзернет на скорости до 90 мегабайт в секунду (больше у нас пока не требовалось). Плюс софт для ПиСихи, там обработка инфы (той самой) на 16-ти ядерном сервере. Ну, так в общих чертах...
ЗЫ. Нет, конечно хорошо, что Вы освоили АСМ, это даёт дополнительные знания и опыт, которые пригодятся (мне тоже пригодились). Но всё-таки считаю это несовременным способом...
Re[2]: Программирование расширения ROM BIOS персонального ко
ССВ>>Авторы: ССВ>> Сазонов Сергей Валерьевич
ССВ>>Аннотация: ССВ>>Расширение PCI ROM BIOS содержит программные компоненты, не входящие по разным причинам в системный BIOS. В статье рассмотрена методика разработки расширения PCI ROM BIOS, упрощающая процесс разработки и уменьшающая количество потенциальных ошибок. Предлагаемая методика актуальна как для PCI-устройств, так и для устройств PCI-Express, т.к. их программная модель конфигурации и расширения ROM BIOS совместима с программной моделью PCI-устройств. E>Большое спасибо за публикацию такой статьи. Очень интересная информация. E>Вопрос к автору. Какие апаратные средства вы можете порекомендовать для отладки ? Я слышал что выбор очень небольшой и это железо стоит очень дорого. Но хотелось бы услышать ваше мнение.
Устройства действительно существуют, и действительно дорогие, потому название их я не запоминал, т.к. все равно не светили. Для отладки можно испоьзовать недорогую комбинацию из трех средств: 1) сетевая PCI-карта с разъмом для ROM-BIOS (удобна тем, что аппаратура точно работает); 2) старый способ-вставка сообщений в критичных местах; 3) хороший осциллогарф или, что лучше логический анализатор
). По поводу сказанного Вами выше, не буду сильно вдаваться в полемику. Скажу только, что Вам не мешало бы КАК СЛЕДУЕТ изучить инструмент под названием Си-компилятор (которым Вы пользуетесь) в части его опций и настроек. Про то, что компиляторы подразумевают наличие операционки и де подключают вне зависимости от Вашей воли какие-то библиотеки, я даже оставлю без комментария, это всё лишь подтверждает то что я сказал.