- Интервью с Д. Кнутом - Codavr(31.07.2020 09:47, zen, ссылка)
- Свидетельство истории. Читать все пункты. Тока не описайтесь. Codavr(78 знак., 30.07.2020 14:35, Off, картинка, полностью)
- Нужен кому генератор синуса? - General(28.07.2020 07:25, Off, ссылка, полностью)
- Самое главное. На Али за десять тыщ? Этакая фиговина? Ребята,
похоже, даже вас могут развести на бабки :) Панацеи нет. Есть
медицина. Больно, не вкусно, долго, не всегда помогает. Но больше
нет ничего. - Бapбoc(30.07.2020 23:22)
- Теперь эта штуковина у меня в рекламе. Кстати, почему бы и нет,
какой-то перец с какими-то шипами. Лучше, чем в среднем по
больнице яндекс-директу. Спасибо, в общем. - SciFi(30.07.2020 10:44)
- кстати очень полезная штука, рекомендую. - m16(28.07.2020 10:17)
- А почему аналоговый генератор использует DMA? - Kpoк(28.07.2020 08:51)
- А зачем покупать генератор синуса, если синус в любой розетке есть? - Ale3000(28.07.2020 08:19)
- Вот вруны. На этикетке нарисован -cos(F) :-) - il-2(28.07.2020 07:33)
- Поступило предложение сделать фильтр от вот этой херни. Браться?
)))) - Rainman62(31.07.2020 08:25, Off, youtube, полностью)
- Технологии можно использовать для создания оружия, способного
"уничтожить всё живое на огромной территории." BlackMorda(171 знак., 29.07.2020 23:13 - 23:42, Off, ссылка, полностью)Evgeny_CD
- Юра прости, мы все про...ли. Все полетели на Марс, китайцы,
американцы и даже арабы в дружбе с Японией _nn(25 знак., 30.07.2020 18:34,
)
- А нам не надо на Марс. Для государственников важнее стабильность -
чтобы так, как сейчас, оставалось вечно :) - Kceния(31.07.2020 00:06)
- "Все прыгнули - и я прыгнул". Это к вопросу за бортом. - Evgeny_CD(30.07.2020 23:55)
- Ну, да. Все уже 7 нм используют, ну а мы делаем на 180нм, за то не
такие , как все. Полимеры просрали, конечно, нам на Марс не надо.
Но каждый год нам говорят, что в таком-то году, лет через 10, мы
обязательно покорим Альтфа Центавра. _nn(58 знак., 31.07.2020 05:42, )
- Им всем осталось самую малость - приземлиться на поверхность Марса
в рабочем состоянии. - Evgeny_CD(30.07.2020 23:54)
- Люди играются, у них на это время и деньги есть. После того как оснастили армию. - ASDFS(30.07.2020 14:36)
- Хм, то есть Nikolay801_(742 знак., 30.07.2020 09:10)
- на фоне Nikolay801_(96 знак., 30.07.2020 08:21, ссылка)
- Да вы все охуели? Всё, что придумали люди, используют сейчас только
для войны грядущей и, самое главное, для отбора средств в пользу
небедных у бедных. В Израиле всё то же самое. Птичку жалко. Но. Бapбoc(84 знак., 29.07.2020 23:47)
- Жалкое подобие группового урока технике пилотировпния для стерхов!
Писателя методички скормить этой доброй птичке. - Evgeny_CD(29.07.2020 23:24)
- У Израиле нет оружия? А у РФ технологий, способных накормить птенцов на огромных территориях? Старый писатель методичек ушел на пенсию и вместо него взяли трех
чернокожих лезбиянок?! - Cкpипaч(29.07.2020 23:17)
- Ищу название цангового контакта, который впаивается в платы. И Как
бы получается он и SMD и в него могут вставляться разьемы без
шлейфа и можно раставлять из как угодно. Бывают разного диаметра. megajohn(1 знак., 30.07.2020 15:33, SCH, картинка, полностью)
- Просматриваю материалы на тему утечек конденсаторов. Может быть
попадалось что то на глаза из этой серии: нужна емкость больше
сотен uF и токи утечки (в домашнем диапазоне температур) максимум
доли uA - Tpoeшник(29.07.2020 15:40, SCH, полностью)
- TMJ S1gma: Xaoc(168 знак., 30.07.2020 20:06,
, ссылка)
- Минимальные утечки у пленочных, только емкость не большая и
напряжение приличное и габариты те еще. - Visitor(30.07.2020 17:20)
- По саморазряду. Зарядить до 5 вольт, все отключить, подождать
несколько минут измерить напряжение, по падению измерить ток
утечки. Nikolay801_(89 знак., 30.07.2020 12:28)
- Слышал что если тантал например 6ти вольтовый ставить на три
вольта, то утечки на порядок уменьшаются. Как их вообще оценить?
Это типа зарядить а потом смотреть прибором разряд? Как минимум
сравнить можно будет несколько конденсаторов - Tpoeшник(30.07.2020 08:13)
- вот, например: - SciFi(29.07.2020 15:43, ссылка)
- HF/50MHz Transceiver TX-500: какая красота, и сделано в Алтайском
крае - megajohn(29.07.2020 17:34 - 19:32, RFID, ссылка, полностью)Evgeny_CD
- У кого-нибудь есть Cosmic STM8 Eval, не требующий
регистрации/активации? Я скачивал как-то с их сайта, просто
устанавливается и работает. Видимо, вычистили всё. Дошло до того,
что заархивировал у себя директорию из program files, её можно
просто скопировать, и всё работает. Но хотелось бы добыть
дистрибутив. - SciFi(30.07.2020 12:16, dao)
- Информация для внимания - при посещения Крыма НЕ советую
авторизовываться, к примеру, в Гитхабе... прислали грозное
письмо... пока курю... sav6622(33 знак., 26.07.2020 19:52 - 20:16, dao, полностью)Evgeny_CD
- Добрый. Нужно на оооочень медленном (0-3 вольта за 10 сек)
повышении питания меги гарантированно стартовать. Как бы попроще
решить. Спс! - Tpoeшник(29.07.2020 08:13, AVR, полностью)
- Приведи пожалуйста ссылку на C стандарт подтверждающую слова: "про
невыравненный доступ сказано -- поведение неопределено"? Уточню:
речь идет о void* указателе. - RxTx(24.07.2020 14:49 - 26.07.2020 13:02, MCU, полностью)fk0
- Сонму копьеметателей: Пощупал конкретнее: В MDK ARM v4 пофиг всякие
#pragma pack(1), __align(4), __packed и их полное отсутствие.
Похоже компилятор, имея в командной строке " --cpu Cortex-M3",
всегда генерит __aeabi_memcpy() в соответствии со здравым смыслом,
имея указатели (void *)... Тут другое интересно - третий параметр в
"шибко грамотном" MDK ARM v5. Что там вещает стандарт?
Руководствуясь тем же здравым смыcлом, там должно быть количество
БАЙТ и компилятор должен Гyдвин(82 знак., 27.07.2020 12:30)
- Где я говорил про void*? Речь про указатель на int. fk0(281 знак., 24.07.2020 15:23)
- Ты написал в прошлом сообщении (цитирую твои слова): "а с некой
абстрактной моделью вычислительной машины заданной СТАНДАРТОМ
ЯЗЫКА". Ты выражение "стандарт языка" понимаешь как-то не так как
все люди? Какие еще "оптимизаторы", какие "кодогенераторы" в
стандарте языка C? Вот я тебя и прошу подтвердить твою же фразу.
Мне еще в 2-3х сообщениях требовать с тебя цитату из стандарта? Или
не будем валять дурака, и ты уже все понял, что по стандарту языка
C прав именно RxTx(558 знак., 24.07.2020 15:53)
- ISO/IEC 9899:201x, разделе 6.3.2.3 Pointers, параграф 7: fk0(851 знак., 24.07.2020 17:18)
- Баг в GCC, а не в Clang и вообще совершенно про противоположное,
мол нет оптимизации. Остального не понял -- научись выражать мысли
на понятном языке. Гудвин не прав, т.к. при использовании
стандартных же любых конструкций языка (без упакованных структур)
"баг" воспроизвести невозможно. А то, что он воспроизводится при
использовании упакованных структур совершенно естесственно, и
кстати в баге gcc есть на это комментарий (см. ссылку) -- вот так
проблему можно обойти. Какие fk0(1225 знак., 24.07.2020 16:56, ссылка)
- Давай укоротим проблему, насколько это возможно, т.к. нет времени и
я устал. С GCC и багом вряд ли я был прав, несмотря на то что
внутри armcc.exe v4 v5 масса строк "GCC" и отсутствует "CLANG",
armcc это отдельный компилятор. В v6 он называется armclang. Со
стандартом вышло смешно. Формально ты привел действительно ровно
то, что я спросил. И бессмысленно утверждать что разумеется вопрос
был о прямых виновниках разговора: о функции memcpy (она оговорена
в стандарте) и о 6.2 RxTx(1116 знак., 24.07.2020 22:30)
- На счёт memcpy: с одной стороны да, ты можешь подсунуть
невыравненный адрес и всё должно работать. И действительно, если ты
руками там как-то аллоцировал память, посчитал адрес, он оказался
невыравненный -- всё будет работать. Будет вызвана "неоптимальная"
версия memcpy. А в случае с гудвиновским багом компилятор был
обманут: ему сказали, что будеут копировать вот такой-то тип, а
этот тип никак не может лежать на невыравненном адресе,
следовательно, компилятор знает, если fk0(1323 знак., 25.07.2020 02:24, ссылка)
- Извини, но ты загнался. LightElf(632 знак., 26.07.2020 14:26)
- Чего ты привязался к memcpy. Я рассказал выше как получается баг. Вместо memcpy может быть любое обращение по указателю/ссылке. К слову и gcc и clang даже варнинг имеют специальный:
-Waddress-of-packed-member. Его невозможно выполнить в любом коде.
А ты хочешь сказать, мол memcpy на 32-битной машине должен
копировать по байтику вместо 4-х за раз, а на 64-битной по байтику
вместо 8, а на машинах где есть векторные инструкции... вообще
страшно. И да, оптимизатор fk0(728 знак., 26.07.2020 15:24)
- Я привязался к memcpy ровно потому, что ее параметры прямо декларируются как void*. void* означает, что указатель может быть любым. И компилятор обязан этот факт учитывать. Тяготы и лишения
компиляторописателей меня интересуют постольку-поскольку. - LightElf(26.07.2020 15:35)
- И он работает с любым типом корректно. Пока ему голову не
заморочили взятием указателя на выровненный тип в упакованной
структуре. В каком-то смысле, это недоработка компилятора, но
стандарт не нарушается. - Nikolay_Po(26.07.2020 15:39)
- Мы говорим о нестандартном (но весьма распространенном) расширении.
Причем тут ссылки стандарт? - LightElf(26.07.2020 15:42)
- ОК. С точки зрения работы расширения проблема налицо. Но fk0
принялся ругать говнокод и защищать компилятор. За что ему большое
спасибо! Всё подробно разжевал, ссылки привёл. Тема была - супер!!! - Nikolay_Po(26.07.2020 15:47)
- Тогда на что ссылаться? По стандарту всё ок. А по мнению LightElf
не ок? Нужен какой-то формальный документ, который описывает
поведение компилятора. - fk0(26.07.2020 15:44)
- На документацию конкретного компилятора - LightElf(26.07.2020 15:48)
- Где в документации описывается что должно происходить в случаях: fk0(232 знак., 26.07.2020 15:59)
- А знаешь почему не описывается? Сям (компилеру и стандарту) просто
чхать, какая там структура. Осознай это. Упакованная, не
упакованная - именно сишечке по барабану. Осознай: требования по
default data alignment (вообще по типам, не только выравнивание, но
и размер) оно существует только для конкретной CPU платформы, не у
компилятора. И padding (выравнивание) структур делает не компилятор
следующий стандарту C, а бэкенд, именно он отвечает за платформу,
ее выравнивание, RxTx(223 знак., 26.07.2020 17:22)
- Логично, что implementation defined behaviour должен быть описан в
документации конкретного implementation. Разве не так? - LightElf(26.07.2020 17:21)
- Я выше сказал, что проблема возникает не в memcpy, а в выражении
&IH.conag. Что там после -- уже не важно. Результат данного
выражения не валиден. Он содержит корректное числовое значение, но
некорректный тип, из-за чего оптимизатор принимает не верное
решение. - fk0(26.07.2020 15:39)
- Опыт жизни и общефилософское наблюдение показывают: дискуссия
(разговор, беседа) только тогда здрава, заканчивается познавательно
и позитивно, когда ее участники имеют одну и ту же цель и
заинтересованы в одном и том же результате. Моя цель в данном
случае - выяснить четкую практическую истину. Где что сломалось,
почему, кто виноват и что делать. Твоя цель явно в том чтобы либо
образовать меня/нас, либо просто изложить (насколько ты понимаешь и
способен) свои представления о RxTx(484 знак., 25.07.2020 10:11)
- Нет, это не баг. Потому, что это UB. Потому, что изначально взяли
указатель на int и присвоили ему что-то, что не является указателем
на int (об чём есть строчка в стандарте). Далее уже не важно. Более
того, ещё раз повторю, в рамках СТАНДАРТНОГО C/C++, возникновение
такого "не бага" -- в принципе невозможно. Оно появляется из-за
"бажной" реализации упакованных структур. Ты прицепился к memcpy и
считаешь, что мол баг. Но класс проблем же НАМНОГО ШИРЕ, чем только
memcpy. fk0(858 знак., 25.07.2020 16:40)
- Вчера я прочитал что ты написал и планировал самостоятельно
поэкспериментировать. Слова это одно, а когда начинаешь разбираться
сам легко может быть другое. Не вышло, нет времени, поэтому все что
я здесь пишу основано на исходных данных этой темы. Кстати беглое
изучение документации на тему memcpy показывает что существует
большое пространство для маневра не только с тривиальными ключами
компилятора, прагмами и атрибутами но и что важно, с подключаемыми
либами/выбором obj RxTx(5329 знак., 26.07.2020 12:46)
- UB значит, что возможное дальнейшее развитие сценария писателями
компиляторов не рассматривается. Такого мол изначально не может
быть, программист не допустит. Поэтому если при анализе ситуации
возникает UB, то нет смысл думать что если то, или если это -- оно
в принципе невозможно в корректной программе. Выражение
"&IH.conag" само по себе UB. Поэтому заявить, что мол в
компиляторе баг и притягивать дальнейшие преобразования типа и
вызов memcpy не нужно: в корректной fk0(4348 знак., 26.07.2020 13:47)
- Я считаю мы с тобой обменялись мнениями. Дальше пойдет уже
непринципиальное, и смысла обсуждать мелочи не вижу. Ты видимо
по-инерции, все еще не осознав или невнимательно, невдумчиво
прочитав мой пост, прибегнул к обсуждению стандарта C. Напрасно,
так как твои посты я перечитывал несколько раз, обдумывал, и даже
заметил что самое первое что ты написал в эту тему - это именно то,
что memcpy должна работать без всяких проблем! А потом у тебя
что-то сломалось :) Так вот, RxTx(758 знак., 26.07.2020 16:46)
- Опять за рыбу деньги. Расширение в виде #pragma pack в GCC есть?
Есть. memcpy в GCC есть? Есть. Где-нибудь в доке GCC написано, что
к элементам пакованной структуры применять memcpy нельзя? Нигде.
Бага GCC очевидна. Чего спорить-то? Хоть бы warning выдавал, как
тот же IAR делает (Used the address of unaligned structure member). - LightElf(26.07.2020 15:08)
- Именно в gcc бага нет, как и в clang последних версий. Они
применяют атрибут меняющий alignof на 1 автоматически. И там
получаются инструкции ldrb при обращении и медленная версия memcpy.
Но ты _доказать_ что это баг в keil или ранних версиях clang -- не
сможешь. Баг в чём? Я выше привёл доказательство, что это UB, a
следовательно не баг. - fk0(26.07.2020 15:27)
- Если компилятор рассматривает void* как int*, то это его
обязанность убедиться в допустимости такой замены в каждом
конкретном вызове. - LightElf(26.07.2020 15:39)
- Так для типа int -- всё корректно. Некорректно для того типа, что
лежит в упакованной структуре. Это не int, потому, что int не может
лежать на невыравненном адресе. Это другой тип. Но в структуре
записано что int, что и приводит к краху. - fk0(26.07.2020 15:43)
- Компилятор знает, что в общем случае void* нельзя приводить к int*.
Компилятор либо знает, что тип лежит в упакованной структуре и
должен генерировать правильный код. Либо компилятор не знает, где
лежит данный конкретный int и тогда должен исходить из худшего (раз
уж он поддерживает такие конструкции). А вот это "здесь читаем,
здесь не читаем, а здесь - рыбу заворачивали" есть косяк и бага. - LightElf(26.07.2020 16:22)
- SciFi же дал ссылку на кейловскую документацию: Taking the address of a field in a #pragma packed struct does
not yield a __packed pointer. Так что это не баг, а фичер: в структуре лежит __packed int, а
берёшь адрес, и брюки превращаются... превращаются брюки...
Идиотизм конечно, но bug report слать действительно бесполезно. - йцyкeн(26.07.2020 15:58, ссылка)
- Спасибо. Убедительно. - Nikolay_Po(26.07.2020 13:58)
- Вы заблудились в сферических абстрацкиях в ваккуме (возможно вместе
с компиляторописателями). В данном случае мы работаем на процессоре
M3 который УМЕЕТ делать unaligned access. Поэтому если компилятор
знает что генерит код для M3 то никакого undefined behavior при
невыровненном указателе на ЭТОЙ архитектуре нет - корректное
исполнение обеспечит hardware. - 3m(26.07.2020 11:42)
- К сожалению, я не пользуюсь Кейлом, поэтому про Кейл ничего не
скажу, но эксперименты с ИАРом показали следующее: во-первых, в
ИАРе воспроизвести эту ошибку не удалось. ИАР заменяет memcpy на
__aeabi_memcpy4, если адреса выронены, и на __aeabi_memcpy, если не
выровнены. Если для невыровненных адресов написать __aeabi_memcpy4
ручками, хардфолт происходит, и здесь нет никакой мистики:
__aeabi_memcpy4 использует инструкции LDM и STM, для которых CM3
как раз не умеет делать йцyкeн(109 знак., 26.07.2020 14:40)
- Умеет делать unaligned access??? Есло бы он умел, то изначально
исключения (в чём собственно баг) при попытке этого самого access
не возникал бы! Чтоб оно так работало надо сбросить битик
UNALIGN_TRP в CCR, а компилятор ни сном, ни духом про SFR регистры
и их значения. Это программист их правильно поставить должен
вначале. Ну там ещё есть такая мелочь, что невыравненный доступ
доступен не для всех инструкций... что тянет за собой отдельную
реализацию всех библиотек fk0(267 знак., 26.07.2020 13:14, картинка)
- undefined behavior -- это йуридическое понятие, а не техническое,
есличо - SciFi(26.07.2020 11:55)
- Отдыхать вам, батенька, надо... Компилятор должен делать то, что
ему явно указали. Все. Конец пустому пиздежу... - Гyдвин(25.07.2020 08:43)
- Я привожу в пример C++ потому, что зная как он работает начинает
приоткрываться принцип работы и C компилятора тоже (благо внутри
там у GCC и Clang для обоих языков один "движок"). В языке C нет
некоторых вещей (шаблонов, ADL), что не даёт понять, например,
почему тип важен и как тип может управлять компиляцией. Для C
программиста может быть не очевидно, а C++ программист запросто
может написать свой самодельный memcpy ровно с такими же "багами"
пользуясь только средствами fk0(196 знак., 25.07.2020 01:57, ссылка)
- armega8. Перестало работать опорное 2,56в. В даташите появилось(?)
указание на то что источник опоры - высокоомный. Cкpипaч(154 знак., 29.07.2020 14:34, AVR, полностью)
- Панаехали, панимаешь. BlackMorda(801 знак., 29.07.2020 18:39, Off, ссылка, полностью)
- наконец-то!!! Нашли в себе силы и как минимум на 156 серверов процы
придется изготовить. В каждом не менее 4 штук. И контракт почти
подписан (если не отменят). Ну что, значит есть еще порох.... klown1(7 знак., 29.07.2020 16:16, Off, ссылка, полностью)
Пьер Ферма, 1601 год
Ледокол Арктика, 1977 год
Холдинг Горизонт запускает производство белорусских планшетов
Создатели процессора более чем с 1000 ядер сворачивают работу и срочно распродают н...
Основанное в 1992 г. АО Электроавтоматика стало ответчиком по иску Минобороны. Во...
Датчики утечки фреона в системах охлаждения дата центров ЦОД Российского про...
Российский завод вложил 118 млрд рублей заемных денег в производство популярных чи...
)
)
