The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Доступен набор компиляторов LLVM 18 , opennews (??), 07-Мрт-24, (0) [смотреть все]

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


34. "Доступен набор компиляторов LLVM 18 "  –1 +/–
Сообщение от Аноним (34), 07-Мрт-24, 16:32 
Оно и не нужно. Это должно быть отдельным файлом. Лучше бы https://github.com/vimpunk/mio стандартизировали.
Ответить | Правка | Наверх | Cообщить модератору

37. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от n00by (ok), 07-Мрт-24, 16:40 
Кому оно должно и зачем путать Си и Си++?
Ответить | Правка | Наверх | Cообщить модератору

42. "Доступен набор компиляторов LLVM 18 "  –7 +/–
Сообщение от Аноним (42), 07-Мрт-24, 17:07 
1. Отображение файлов в память с удобным в работе кроссплатформенны  интерфейсом, встроенным в стандартную библиотеку? Всем нужно.
2. Си устарел и не нужен. Для адекватных людей чистого си в их проектах не существует. К сожалению иногда приходится иметь дело с неадекватными, вроде некоторых разработчиков Дебиана (кстати, подписантов антистоллмановского письма).
Ответить | Правка | Наверх | Cообщить модератору

52. "Доступен набор компиляторов LLVM 18 "  +2 +/–
Сообщение от n00by (ok), 07-Мрт-24, 17:30 
Мне не нужно вот такое отображение в стандарте - оно полурабочее и скатывает Linux до некоего среднего арифметического (в #40 указал, почему).
Ответить | Правка | Наверх | Cообщить модератору

71. "Доступен набор компиляторов LLVM 18 "  +1 +/–
Сообщение от An (??), 07-Мрт-24, 20:48 
Как устарел?
В BSD/Linux в ядрах и базе он основной, и подавляющее большинство PR в сорцы этих систем до сих пор на нем летит.
Много хорошего прикладного софта на нем до сих пор пишется.
Разве так устаревают?
Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

95. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (95), 08-Мрт-24, 18:38 
Так адекватность теряют.
Ответить | Правка | Наверх | Cообщить модератору

102. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (44), 09-Мрт-24, 07:31 
Линуксу сколько лет, напомнить? Да и можно подумать, у Торвальдса с его 386 особый выбор был.
Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

48. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (48), 07-Мрт-24, 17:19 
>Кому оно должно

Поддерживать порочные практики с вкомпиленными в бинарник ресурсами — не должно. Храните файлы на диске и отображайте в память.

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

51. "Доступен набор компиляторов LLVM 18 "  +1 +/–
Сообщение от n00by (ok), 07-Мрт-24, 17:29 
Порочная практика - это писать "должно", не понимая смысл слова. Покажите договор или стандарт.
Ответить | Правка | Наверх | Cообщить модератору

60. "Доступен набор компиляторов LLVM 18 "  –1 +/–
Сообщение от Аноним (60), 07-Мрт-24, 19:02 
1. https://refspecs.linuxfoundation.org/fhs.shtml
2. https://specifications.freedesktop.org/
Ответить | Правка | Наверх | Cообщить модератору

103. "Доступен набор компиляторов LLVM 18 "  +1 +/–
Сообщение от n00by (ok), 09-Мрт-24, 08:24 
> 1. https://refspecs.linuxfoundation.org/fhs.shtml

Это вообще каким боком?

> 2. https://specifications.freedesktop.org/

И с какой стати вот это должно распространяться на всё? В исходном сообщении процитирован стандарт языка.

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

137. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (137), 12-Мрт-24, 13:32 
1. Таким. И иконки хранятся строко в виде файлов по определённым путям.
2. А с какой стати твои хотелки, чтобы с компов можно было тырить #embed "~/.ssh/id_rsa" и #embed "/proc/cpuinfo", должны воплощаться в реальность? С той, что они совпадают с хотелками спецслужб, представители которых оказывают влияние на комитеты?
Ответить | Правка | Наверх | Cообщить модератору

141. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от n00by (ok), 12-Мрт-24, 20:19 
1. Не надо зацикиваться на иконках.
2. Не надо параноить, когда по существу ответить нечего.
Ответить | Правка | Наверх | Cообщить модератору

62. "Доступен набор компиляторов LLVM 18 "  +2 +/–
Сообщение от Аноним (62), 07-Мрт-24, 19:15 
Опять в интернете вижу новости из параллельных вселенных. У вас там микроконтроллеры не существуют? Или они все идут с дисками и поддержкой проекции в память, или для них не изобрели дисплейчики куда можно текст и картинки выводить?
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

64. "Доступен набор компиляторов LLVM 18 "  –2 +/–
Сообщение от Аноним (64), 07-Мрт-24, 19:26 
А какие проблемы с контроллерами, кроме мизерной памяти? Интерфейс от этого не зависит, а фс можно использовать специализированную. в виде идельной хэш-таблицы с хэшированием в compile-time, храня все "файлы" в ПЗУ. А если не можешь использовать интерфейс отображения страниц памяти - просто не подключай этот хедер в свою программу.
Ответить | Правка | Наверх | Cообщить модератору

104. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от n00by (ok), 09-Мрт-24, 08:30 
> А какие проблемы с контроллерами, кроме мизерной памяти?

Вместо #embed приходится самостоятельно конвертировать в пригодный для #include вид, но не каждый умеет написать для того скрипт на Perl, потому принимается выдумывать на тему файлов.

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

108. "Доступен набор компиляторов LLVM 18 "  +1 +/–
Сообщение от Аноним (-), 09-Мрт-24, 09:45 
> А какие проблемы с контроллерами, кроме мизерной памяти? Интерфейс от этого не
> зависит, а фс можно использовать специализированную. в виде идельной хэш-таблицы с
> хэшированием в compile-time, храня все "файлы" в ПЗУ.

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

И вот это все - вместо 1 строчки в сорце?! Серьезно?

> А если не можешь использовать интерфейс отображения страниц памяти - просто не подключай этот
> хедер в свою программу.

Прекрасно - и тогда бинарный ресурс в фирмвару мы инклюдим, например, как?! И еще, у МК как правило нет MMU и страниц.

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

117. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (117), 09-Мрт-24, 16:38 
>Вот сейчас притащим специально для этого код парсинга всего этого счастья

Ну тебе же не западло целый ico-файл со всеми хедерами втащить?

>Прекрасно - и тогда бинарный ресурс в фирмвару мы инклюдим, например, как?!

Если у вас хилый контроллер, и вам надо бинарные ресурсы в прошивку вкомпиливать, то вы делаете всё неправильно. Либо крестик снимите, либо трусы наденьте. Ресурсы в виде готовых бинарных файлов нужны ровно в одном случае — у вас там веб-сервер сидит и их отдаёт. Что исключает хилый контроллер и уже требует файлосистему. Которая может быть очень простой и виртуальньй:

1. компилятор ресурсов берёт ресурсы по именам, и генерит perfect hash function. Причём constexpr.
2. он же генерит файл с ресурсами, просто таблица. 0 — 1 файл, 1 - другой файл, 2 - третий файл, 3 - четвёртый файл.
3. в коде ресурсы идут по путям, но компилятор их прямо при компиляции хэширует и прямо при компиляции выполняет lookup в таблице. C++23.
4. а если надо в динамике - то код для функции компилятор засунет.

Если же у вас таблица коэффициентов, напр. для термопары, то вам надо её инклюдить, причём как consexpr, а не как байты копировать. Компилятор разберётся лучше, забить ему таблицу в машинный код прямо в инструкции, или хранить как таблицу и считать по алгоритму.

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

121. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от An (??), 10-Мрт-24, 12:49 
Сделать извращенными через одно место, чтобы удовлетворить запрос одного анонима. В стандарте все решается одной строчкой, но аноним считает, что лучше каждый раз извращаться через таблицы, чтобы прилинковать бинарный файл, который задается на этапе компиляции.
Ответить | Правка | Наверх | Cообщить модератору

136. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (137), 12-Мрт-24, 13:21 
Возможность делать такие вещи одной строчкой обернётся тем, что через неё начнут тырить с компов секретные данные.
Ответить | Правка | Наверх | Cообщить модератору

129. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (-), 11-Мрт-24, 13:52 
> Ну тебе же не западло целый ico-файл со всеми хедерами втащить?

Классические ico файлы и их хидеры - весьма мелкие, и довольно просты в парсинге. Особенно если договориться о каких-то constraints. Ибо дедалось в эпоху царя гороха еще, когда компы были крупнее и дохлее. Самое что надо для МК с ограниченными ресурсами, стало быть.

>>Прекрасно - и тогда бинарный ресурс в фирмвару мы инклюдим, например, как?!
> Если у вас хилый контроллер, и вам надо бинарные ресурсы в прошивку
> вкомпиливать, то вы делаете всё неправильно.

ORLY? То-есть например фонт чтобы немного порисовать на небольшом LCD или OLED мне не надо? И да, он может быть диагональю менее дюйма, даже чернобелый, на i2c или spi, так что это своротит даже самый паршивый МК. Но текст же на массив пикселей надо как-то отрендерить, мистер эксперт?!

> Либо крестик снимите, либо трусы наденьте.

Мне такой выбор не нравится - поэтому я в моих проектах буду вон то юзать, уж сорян. А если у вас они не соберутся? Упс, читаете requirements и обеспечиваете это. Или ищете другой проект.

> Ресурсы в виде готовых бинарных файлов нужны ровно в одном
> случае — у вас там веб-сервер сидит и их отдаёт.

Булшит бинго. Скажем если к МК прицеплен небольшой LCD или OLED - сразу начинает хотеться как минимум фонт почему-то. А иногда и ряд иных вещей. А вот зачем мне ФС и код ее парсинга чтобы пару строчек на OLED микроскопический порисовать?!

> Что исключает хилый контроллер и уже требует файлосистему.

В каком месте желание вывести пару строк статуса на мизерный OLED размером сантиметр на два "требует файловую систему"?! Вы там того?

> Которая может быть очень простой и виртуальньй:

А нафиг мне ФС в вон том кейсе? И прочие "файловые операции". Оно в сумме весить будет - как пять фонтов для вон того.

> 1. компилятор ресурсов берёт ресурсы по именам,

Вау, то-есть мне еще и это надо кодить и/или наруливать в билде фирмвари? Вместо 1 строки инклюда?

> и генерит perfect hash function. Причём constexpr.

Ага, вместо 1 строки кода то...

> 2. он же генерит файл с ресурсами, просто таблица.

А зачем мне вообще абстракция файлов в той штуке вперлась? Там фонт вообще - один на всю систему, hardwired, и ЭТО своротит - блин, даже PIC и прочий AVR. Или там какой cortex M0 самый копеечный, да даже вон тот RISCV за 0.2 бакса. Но вот куда там ФС то?...

> 3. в коде ресурсы идут по путям, но компилятор их прямо при
> компиляции хэширует и прямо при компиляции выполняет lookup в таблице. C++23.

Себе его оставьте, имхо. У C++ все намного сложнее с сетапом арены и ее предсказуемостью, и я таки предпочитаю си в простых фирмварах с повышенными требованиями к надежности и предсказуемости. Это никак не исключает желание отрисовать до кучи допустим статус на мелкий экранчик типа oled или lcd на какомнить i2c или spi. И вот там инклюдануть что-то типа фонта вот так - очудобно!

> 4. а если надо в динамике - то код для функции компилятор засунет.

F...k overengineering!

> её инклюдить, причём как consexpr, а не как байты копировать.

Мне инклюд объекта как "const" вполне нормуль. Хотя такие вещи по хорошему лучше runtime калиброваками все же делать. На случай уплывания параметров или замены термопары.

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

Предпочитаю иметь явный контроль над данным аспектом для информированного принятия решения как оно мне надо, а не то что там компилятор себе удумает по рандому. В фирмвари я предпочитаю плотный контроль layout результата и что у меня где. Например чтобы при случае допустим runtime калибровки уметь. Даже возможно отдельным модулем - сохраняющим их в well defined area. Это кстати не я придумал, но идею ессно упер :)

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

135. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (135), 12-Мрт-24, 13:04 
>Классические ico файлы и их хидеры - весьма мелкие, и довольно просты в парсинге.

Для вывода файла тебе его придётся предобработать и прокешировать предобработанный результат в оперативу, которая очень ограниченный и дорогой ресурс на микроконтроллерах. Гораздо лучше сделать предобработку на хосте, а на контроллер шить уже готовый результат, который не будет занимать оперативу и который можно использовать прямиком из NVRAM.

>То-есть например фонт чтобы немного порисовать на небольшом LCD или OLED мне не надо

Надо, но не в виде BMP/PNG/JPG файлов со всеми XMP и EXIFами.

>А вот зачем мне ФС и код ее парсинга чтобы пару строчек на OLED микроскопический порисовать?!

Где код парсинга ФС в 1) вычислении perfect-хэша от строки 2) использования полученного числа в качестве индекса в таблице указателей 3) дальнейшего разыменовывания указателя (если у тебя сиволы одинакового размера, то размер для каждого хранить не нужно)?

>F...k overengineering!

Оверинжиниринг — это хардкодить в бинарь картинки целиком.

>Хотя такие вещи по хорошему лучше runtime калиброваками все же делать. На случай уплывания параметров или замены термопары.

Полностью согласен, что в устройстве должен быть режим калибровки и смены коэффициентов.

>Предпочитаю иметь явный контроль над данным аспектом для информированного принятия решения как оно мне надо, а не то что там компилятор себе удумает по рандому

А вот я проанализировав выхлоп clang на O3 понял, что намного лучше это доверить компилятору, ибо мой ручной ассемблерный код был в несколько раз медленнее. Потому что Clang использует для оптимизации SMT-решатель.

>В фирмвари я предпочитаю плотный контроль layout результата и что у меня где. Например чтобы при случае допустим runtime калибровки уметь. Даже возможно отдельным модулем - сохраняющим их в well defined area. Это кстати не я придумал, но идею ессно упер :)

Если ты хардкодишь таблицу в прошивку на уровне исходника, то смена коэффициентов hex-редактированием нерелевантна. Если ты выделяешь регион под свою структуру данных — то надо сделать и программу-редактор и прошивальщик, а хардкодить в прошивку на уровне исходников — не надо.

>Ага, вместо 1 строки кода то...

Эта строка кода может утащить у тебя с машины любой файл с секретной информацией на предскадуемом размещении. Просто собирать программу на своей машине станет опасно. Давай ещё введём команду препроцессора #command "!/usr/bin/env rm -rf~/" тогда уж, чтобы до уровня Раста провалиться.

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

40. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от n00by (ok), 07-Мрт-24, 16:50 
https://github.com/vimpunk/mio

А это правильно, что не добавили.

Вот это зачем?


inline size_t page_size()
{
    static const size_t page_size = []
    {
#ifdef _WIN32
        SYSTEM_INFO SystemInfo;
        GetSystemInfo(&SystemInfo);
        return SystemInfo.dwAllocationGranularity;
#else
        return sysconf(_SC_PAGE_SIZE);
#endif
    }();
    return page_size;
}

И где там mremap, в котором вся прелесть?
Если хотите мапить файлы стандартным образом - ну дык допилите работу с файлами в стандартной библиотеке, там же возможна буферизация, а детали реализации не оговариваются.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

45. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (45), 07-Мрт-24, 17:13 
Смысл не в том, чтобы втащить mio в стандартную библиотеку целиком как есть — разумеется все проблемы существующей реализации должны быть устранены (мне вообще крайне не нравится, что возвращаемые типы не наследуются у std::span<нужный тип>, и поэтому мне приходится это делать самому, и уже работать с std::span). И ремаппинг безусловно должен быть, как и отображение-выделение страниц без файлов, отображение анонимных страниц, и страниц, общих для нескольких процессов — мне из-за этого пришлось свой велосипед написать. Смысл в том, что отображение файлов в память нужно всем, но почему-то его нет в стандартной библиотеке, и приходится возится с васянозависимостями.
Ответить | Правка | Наверх | Cообщить модератору

47. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (45), 07-Мрт-24, 17:14 
*возиться
Ответить | Правка | Наверх | Cообщить модератору

53. "Доступен набор компиляторов LLVM 18 "  +1 +/–
Сообщение от n00by (ok), 07-Мрт-24, 17:36 
А проблемы не будут устранены, потому что механизмы ОС различаются. Вон в Cygwin сделали ремаппинг стандартным образом - через memcpy, можете использовать. ;)
Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

61. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (60), 07-Мрт-24, 19:06 
Не так уж сильно и различаются:
* выделение пустых страниц
* задание им флагов доступа
* их освобождение
* отображение файла в память

есть везде! А для отличающихся нюансов — ну так никто и не запрещал юзать системное API на std::begin(allocatedPageSpan).

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

105. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от n00by (ok), 09-Мрт-24, 08:33 
Я понимаю, что тут каждый Аноним умнее создателей Cygwin, даже если никогда не работал с секциями в NT и потому пропустил в плане "зарезервировать страницы". Но это в теории. На практике внутри mramap() почему-то до сих пор memcpy().
Ответить | Правка | Наверх | Cообщить модератору

74. "Доступен набор компиляторов LLVM 18 "  +1 +/–
Сообщение от _kp (ok), 07-Мрт-24, 22:22 
Тут пример просто в котором полезность фичи не раскрывается, а только показан способ как можно.
Как минимум в embedded это весьма полезно.
Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

91. "Доступен набор компиляторов LLVM 18 "  +/–
Сообщение от Аноним (-), 08-Мрт-24, 16:58 
> Оно и не нужно. Это должно быть отдельным файлом.

А таки в gcc уже завезли, и это удобно.

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

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

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




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

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