The OpenNET Project / Index page

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



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

Оглавление

Анализ использования ассемблерных вставок в коде открытых пр..., opennews (??), 02-Апр-13, (0) [смотреть все]

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


3. "Анализ использования ассемблерных вставок в коде открытых пр..."  –2 +/
Сообщение от TbIK (ok), 02-Апр-13, 13:32 
Разве для оборудования нет Си-шных функций записи в порты??
Ответить | Правка | Наверх | Cообщить модератору

8. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от Аноним (-), 02-Апр-13, 14:33 
чего?
Ответить | Правка | Наверх | Cообщить модератору

10. "Анализ использования ассемблерных вставок в коде открытых пр..."  +1 +/
Сообщение от анон (?), 02-Апр-13, 14:41 
си
Ответить | Правка | Наверх | Cообщить модератору

9. "Анализ использования ассемблерных вставок в коде открытых пр..."  –1 +/
Сообщение от dalco (ok), 02-Апр-13, 14:41 
Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не то, что под каждую архитектуру, а, скорее, под каждый новый чип делать.

Фактически, эта функция и будет ассемблерной вставкой :)

Или я не прав?

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

16. "Анализ использования ассемблерных вставок в коде открытых пр..."  +3 +/
Сообщение от Аноним (-), 02-Апр-13, 14:52 
> Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не
> то, что под каждую архитектуру, а, скорее, под каждый новый чип
> делать.
> Фактически, эта функция и будет ассемблерной вставкой :)
> Или я не прав?

Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином "порт", о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора.
Но если очень грубо - да, это так :)

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

28. "Анализ использования ассемблерных вставок в коде открытых пр..."  +4 +/
Сообщение от pavlinux (ok), 02-Апр-13, 16:27 
>> Вряд ли такое возможно. Это же необходимо свою индивидуальную версию Си не
>> то, что под каждую архитектуру, а, скорее, под каждый новый чип
>> делать.
>> Фактически, эта функция и будет ассемблерной вставкой :)
>> Или я не прав?
> Угрожающе надвигается долгий-долгий разговор о том, что автор понимает под термином
> "порт",о прямом доступе к портам ввода-вывода и маппировании, о режимах процессора.

include/asm-generic/io.h

static inline void __raw_writeb(u8 b, volatile void __iomem *addr)
{
         *(volatile u8 __force *) addr = b;
}

#define writeb __raw_writeb

static inline void outb(u8 b, unsigned long addr) {
        writeb(b, addr + PCI_IOBASE);
}
...
и т.д.

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

58. "Анализ использования ассемблерных вставок в коде открытых пр..."  +2 +/
Сообщение от skb7 (ok), 02-Апр-13, 23:25 
Посыл топика -- ответить на вопрос, как на Си писать в порты. Ваш К.О.

Зачастую оборудование висит прямо на шине памяти, тогда запись регистры этого оборудования производится точно также, как и запись в память. Не вижу проблемы, чтобы выполнять такую запись по адресу из Си:

  *((unsigned int *)0x4ae04030) = 0xdeadbeef;

На самом деле всё немного сложнее и нужно делать ioremap(), чтобы отобразить адреса i/o в память, и потом в эту память записать нужное значение -- т.о. регистр будет содержать записанное значение.

Всё описанное должно выполняться в пространстве ядра, естественно.

Более подробно можно почитать тут:
http://rus-linux.net/MyLDP/BOOKS/drivers/linux-device-driver...
http://rus-linux.net/MyLDP/BOOKS/drivers/linux-device-driver...
http://www.makelinux.net/ldd3/chp-9-sect-4

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

65. "Анализ использования ассемблерных вставок в коде открытых пр..."  –1 +/
Сообщение от ананим (?), 03-Апр-13, 01:04 
 >*((unsigned int *)0x4ae04030) = 0xdeadbeef;

И чем это лучше ассемблера?

Зыж
Вопрос не в языке и их хэйтерах. Не в ловле ведьм.
А в ПЕРЕНОСИМОСТИ.
Этот код будет таким же баластом на "чужой" платформе.
Только а) его уже йюх отследишь (как асм в сабже) и б) где ифдифы? В связи с очередным готу-джихадом на них будет больше индусов.

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

66. "Анализ использования ассемблерных вставок в коде открытых пр..."  –1 +/
Сообщение от ананим (?), 03-Апр-13, 01:06 
Ззыж
 >*((unsigned int *)0x4ae04030) = 0xdeadbeef;
Вообще йюх поймёшь что эти цифири значат.
Заучить?
Ответить | Правка | Наверх | Cообщить модератору

71. "Анализ использования ассемблерных вставок в коде открытых пр..."  –1 +/
Сообщение от Аноним (-), 03-Апр-13, 04:46 
>  >*((unsigned int *)0x4ae04030) = 0xdeadbeef;
> Вообще йюх поймёшь что эти цифири значат.

Поэтому нормальные люди таки дают читаемые обозначения константам. Или накрайняк хоть комент рядом пишут.

Чисто технически этот код записывает значение 0xdeadbeef по адресу 0x4ae04030. Но вот чем адрес 0x4ae04030 так примечателен на фоне остальных 4 миллиардов - из такой записи само по себе никак не видно.

С другой стороны, var_4ae04030 = 0xdeadbeef можно написать на любом ЯП. Будет настолько же понятно WTF :).

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

76. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от ананим (?), 03-Апр-13, 06:02 
Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без дополнительного портирования так как ассемблерный код используется только для оптимизации и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных возможностей, что не блокирует сборку приложения на новых архитектурах.
Ответить | Правка | Наверх | Cообщить модератору

77. "Анализ использования ассемблерных вставок в коде открытых пр..."  –1 +/
Сообщение от ананим (?), 03-Апр-13, 06:06 
Т.е., другими словами, нормальные люди читают выводы:
> Большинство пакетов с ассемблерными вставками будут работать на других архитектурах без
> дополнительного портирования так как ассемблерный код используется только для оптимизации
> и предусматривает наличие замены на C/C++ или связан с реализацией дополнительных
> возможностей, что не блокирует сборку приложения на новых архитектурах.

А не придумывают свой "хрень на плетень".
Давай, запрограммируй sseX, 6 и более параметров в fast system call и т.д.

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

78. "Анализ использования ассемблерных вставок в коде открытых пр..."  –1 +/
Сообщение от ананим (?), 03-Апр-13, 06:11 
Зыж
>Чисто технически этот код записывает значение 0xdeadbeef по адресу 0x4ae04030. Но вот чем адрес 0x4ae04030 так примечателен на фоне остальных 4 миллиардов - из такой записи само по себе никак не видно.

Да похер чем он там знаменит, ГЛАВНОЕ — он аппаратн-зависим.
И его хер найдёшь автоматом (регекспом, пока чашку кофе на кухне куришь), как ассемблерную вставку.
Результат будет ещё плачевен.

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

90. "Анализ использования ассемблерных вставок в коде открытых пр..."  +2 +/
Сообщение от skb7 (ok), 03-Апр-13, 11:56 
Было показано, что на Си можно выполнить запись в порт. Приведенный код -- просто пример, как это может быть сделано. Насчет именованных констант и переносимости -- сожалею, если вы хотели использовать это ПРИМЕР в продакшн-коде. Для этого есть переносимые iowrite/ioread и т.д., как выше моего поста показал pavlinux, их и используйте.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

88. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от Аноним (-), 03-Апр-13, 11:12 
> Посыл топика -- ответить на вопрос, как на Си писать в порты.
> Ваш К.О.

В таком случае - сам задал вопрос, сам и ответил. Загляните в начало ветки.
"Разве для оборудования нет Си-шных функций записи в порты??"

Итак, ответ - нет. То что ваш код можно написать - кто бы спорил, на Си вообще можно написать много чего.

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

70. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от Аноним (-), 03-Апр-13, 04:43 
> static inline void outb(u8 b, unsigned long addr) {
>         writeb(b, addr + PCI_IOBASE);

Вот только в этом месте скорее всего порылся архитектурно-специфичный асм, если оно реально выводит в I/O порт а не memory-mapped аналог.

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

94. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от pavlinux (ok), 03-Апр-13, 15:39 
>> static inline void outb(u8 b, unsigned long addr) {
>>         writeb(b, addr + PCI_IOBASE);
> Вот только в этом месте скорее всего порылся архитектурно-специфичный асм, если оно
> реально выводит в I/O порт а не memory-mapped аналог.

#ifndef PCI_IOBASE
#define PCI_IOBASE ((void __iomem *) 0)
#endif

# define __iomem  __attribute__((noderef, address_space(2)))

:)

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

107. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от Аноним (-), 05-Апр-13, 13:01 
> # define __iomem  __attribute__((noderef, address_space(2)))

Ок, продолжаем разгадки ребусов :) а что в этих определениях? :)


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

19. "Анализ использования ассемблерных вставок в коде открытых пр..."  +2 +/
Сообщение от BSA (?), 02-Апр-13, 15:19 
А причем тут запись в порты? Если посмотришь исходники ядра, то там для этого специальные функции используются.
Более того, не у всех процессоров есть "порты". Например, у ARM "порты" находятся в общем адресном пространстве - запись в порт на ассемблере ничем (кроме адреса) не отличается от записи в память.
Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

72. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от Аноним (-), 03-Апр-13, 04:47 
> находятся в общем адресном пространстве - запись в порт на ассемблере
> ничем (кроме адреса) не отличается от записи в память.

Собственно практически вся современная периферия - memory mapped в основное пространство. Порты в том виде как у х86 - пережиток древних времен.

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

68. "Анализ использования ассемблерных вставок в коде открытых пр..."  +/
Сообщение от Аноним (-), 03-Апр-13, 04:39 
> Разве для оборудования нет Си-шных функций записи в порты??

Именно в порты - только через функции-хелперы (в которых ASM вероятно все-таки будет), потому что все это - в отдельном адресном пространстве. По этой причине в современных архитектурах периферия обычно memory mapped и живет в основном адресном пространстве. Так ее из сей удобнее.

Но кроме портов, например DCT преобразование в кодеке выписанное на аккуратном SIMD ассемблере таки в несколько раз быстрее той галиматьи которую на этом коде сишный компилер сгенерит. А вот когда fullhd видео не укладывается в реалтайм и дропает кадры - это печально.

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

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

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




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

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