Линукс выкинут

Законы физики мешают использовать стандартизированные интерфейсы и протоколы не больше, чем разрабатывать само железо.

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

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

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

это случай так называемого вранья. особенно - про LLVM.

Дай угадаю: ты приведёшь в пример Hello World.

Есть места, куда лучше своими руками с ассемблером не лезть, так как будет говнокод с тормозами.

вот это типичное мнение чистых виртуальных программистов, которые никогда в жизни с железом не имели дел.

Программист не должен решать проблемы разработки железа. Разделение труда не просто так придумано.

потому я и говорю - тыкать носом в отладку железа. только так это можно понять.

Дай угадаю: не получился стандартный UART из-за законов физики (на самом деле из-за лени или кривых рук), и программист должен работать с каким-то нестандартным UART? АЦП рандомно начинает выдавать всякий бред до определённого разряда, если не в тот регистр определённое значение записать, и программист должен это учитывать? Может ещё Rowhammer припомнить, который признали ошибкой разработчиков железа, а не виной программистов? Не... Кривым железом лучше не пользоваться изначально.

нет. есть огромные библиотеки на ассемблере. и эффективнее них ещё никто ничего не написал. человеческий мозг работает заведомо лучше любого оптимизатора. потому что оптимизатор написан людьми.

Программист не должен решать проблемы разработки железа. Разделение труда не просто так придумано.

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

к чему это всё? это к тому, почему вендоры не любят стандарты и им часто просто некогда причёсывать код для коммитов в главную ветку. я их отлично понимаю. у них и без этого проблем хватает.

нет. есть огромные библиотеки на ассемблере.

Вот и подбираемся к сути.

и эффективнее них ещё никто ничего не написал.

А ничего, что для ряда задач таких библиотек нет и не будет, так как на тот же LLVM всё перекидывают?

человеческий мозг работает заведомо лучше любого оптимизатора. потому что оптимизатор написан людьми.

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

к чему это всё? это к тому, почему вендоры не любят стандарты и им часто просто некогда причёсывать код для коммитов в главную ветку.

Есть средства, с помощью которых не требуется коммиты в главную ветку делать. Ими вендоры пользоваться наотрез отказываются и нередко лепят свои велосипеды для этого, которые на деле даже хуже стандартных. Это просто факт.

не получился стандартный UART
Кривым железом лучше не пользоваться изначально.

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

Человеческий мозг сильно ограничен в переборе и количественном анализе.

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

ты живёшь в виртуальном мире розовых единорогов. нет никакого «стандартного UART». есть конкретные реализации. плюс-минус разные погрешности и несовместимости. железо всегда «кривое». по определению. даже двух совершенно одинаковых плат не бывает. везде есть допуски, на всех уровнях.

Ты путаешь допуски с неприемлемо большими отклонениями, которые выходят за рамки спецификаций.

суть в том, что перебор возникает лишь потому, что машина не понимает смысла задачи. и решает её в лоб.

Нет - перебор возникает потому, что гораздо быстрее перебрать кучу вариантов, чем полагаться на вероятность.

а человек понимает и решает её, исходя из смысла. ему перебор не нужен.

Ещё как нужен. Хотя бы потому, что человек не может знать всё. Именно по этой причине и был создан компьютер - автоматизировать рутину. Больше ни для чего компьютер не нужен.

и ещё раз: нельзя написать программу-оптимизатор, которая «умнее» разработчика. это уже метафизика.

Можно написать (и уже написали) программу-оптимизатор, которая справляется с задачей эффективнее большинства разработчиков.

Ты путаешь допуски с неприемлемо большими отклонениями, которые выходят за рамки спецификаций.

я просто работала с реальным железом. и я тебе в третий раз повторяю: спецификации существуют только на бумаге. в реальном железе есть реализации. и там как повезёт.

которая справляется с задачей эффективнее большинства разработчиков.

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

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

А причём тут ассемблер-то. И на жабке можно «применить другой алгоритм или изменить разделение задач» (C)

ассемблер - это тоже планирование структуры и алгоритмы. только ещё более точно и гораздо более эффективно.

На ассемблере писать только не совсем удобно. На джаве тоже неудобно, но категории всё-таки разные.

Но начинание — компилить жаву очень хорошее.

Рантайм везде одинаковый.

Расскажи это Mediatek.

Вот только в андроиде никогда не было JVM.

А я писал что он был? Может ты будешь читать сообщения как они есть и не придумывать?

Туда коммитят участники Open Handset Alliance - владельца и разработчика андроида.

Наверное. Но большинство таки гугл и email в коммитах и владельцев репозиториев немного намекает.

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

А что вне ядра и драйверов mediatek натворил?

А я писал что он был?

Это обсуждение в контексте тезиса «в андроиде есть жаба».

и я тебе в третий раз повторяю: спецификации существуют только на бумаге. в реальном железе есть реализации. и там как повезёт.

То есть, делают не работающее железо, а выпускают что попало, и это ты считаешь тем, что и должно быть. Ясно.

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

понятие «эффективней» в лексиконе манагеров обычно обозначает скорость. но не качество.

Речь не про манагеров. Речь про трудозатраты и результат. На ассемблере для достижения максимальной эффективности придётся убить столько времени, сколько не будут использовать программу.

человек понимает гораздо больше, чем любой алгоритм.

Опять же: такой подход применим только когда задача укладывается в написание небольшого объёма кода. Если система сложная и кода много, то ассемблер автоматически идёт нафиг вместо с предлагающими на нём писать больше 10% всего кода.

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

Именно это от оптимизатора и требуется. Подход выработан.

То есть, делают не работающее железо, а выпускают что попало, и это ты считаешь тем, что и должно быть.

нет. это не «я считаю». это просто так было, так есть и так будет. добро пожаловать в реальную жизнь :) физика и электроника - это не сферические кони в вакууме. и чем выше частота - тем больше влияние всякой НЁХ. а частота имеет тенденцию повышаться.

HAL это тоже важная часть и она не в ядре. Во фреймворке вообще не известно что творили. Поэтому никто в здравом уме кастомы не пилит на mediatek. А кто пилит — получает полурабочий кирпич.

А вон ещё Samsung. У них давным давно уже свой форк Android с потерянной совместимостью. Если бы ты писал софт, а не только чесал языком, то бы знал. Именно Samsung доставляют больше всего проблем. Не было бы их положения на рынке, то значительная часть софта у них бы не работала.

То есть, делают не работающее железо, а выпускают что попало, и это ты считаешь тем, что и должно быть. Ясно.

Так не должно быть, но так есть и так будет всегда. Лечить софтом ошибки разработчиков железа - да. А иначе машинка не работает. Только если эльфы да гномы за работу возьмутся.

А разве от патча меняют автора коммита? Обычно стоит X commited with Y.

ассемблер - это тоже планирование структуры и алгоритмы.

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

вопрос в том, жаба ли это?

Нет - не жаба изначально. От жабы там только язык был, и то это не самая важная часть. Сначала там своя виртуальная машина Dalvik была, а теперь её заменили на транслятор в родной код с рантаймом ART. Переносимость не потерялась, а безопасность можно и без жабы сделать.

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

Именно так NDK и работал, когда требовалось напрямую ресурсы железа использовать.

но тогда и компиляция особо не улучшит производительности.

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

есть огромные библиотеки на ассемблере. и эффективнее них ещё никто ничего не написал.

Ты не понимаешь о чём говоришь. На ассемблере можно написать суперэффективный код. Но выпускает Интел новый камень, и всё байтодрочество превращается в тыкву. Более того, Интел уже навыпускал хренову тучу камней, под которые методы оптимизаций радикально разные. Почитай книжечку господина Касперского, там всё с картинками и примерами.

физика и электроника - это не сферические кони в вакууме. и чем выше частота - тем больше влияние всякой НЁХ. а частота имеет тенденцию повышаться.

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

HAL это тоже важная часть и она не в ядре.

Это не рантайм.

Во фреймворке вообще не известно что творили.

А вот это уже интереснее.

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

Это не «не стали», это банально дороже и займёт больше времени. А у бизнеса есть конкретные бюджеты и сроки.

Лечить софтом ошибки разработчиков железа - да.

Так и я о том же - вынужденная мера, но это неправильно. Я понимаю, что есть выпущенные экземпляры, которые выкидывать просто так нельзя, и к ним готовят всякие errata. Но Iron_Bug в недоработках инженеров обвиняет программистов, которые продуктом в итоге пользоваться будут.

Это не «не стали», это банально дороже и займёт больше времени.

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

Да тут вроде никто и не говорит, что это правильно. Всё правильно только у эльфов. Тут дело не в поиске виноватого, а в том, что работу надо сделать.

нее, не всё так плохо. вот как раз у интела преемственность архитектуры очень даже хороша. ну, добавится там пара-тройка новых инструкций - и всё. глобально архитектура внутри одной линейки почти не меняется. во всяком случае, не принципиально. они же не враги сами себе. они микрокод пишут для своих процов. да и писателям компиляторов они свинью подложить не могут. совсем новый проц не сможет юзать никто. у Intel так вышло с Itanium'ами: процы появились на рынке, а осей, которые бы их поддерживали, просто не было. вот и конец инновации.

но нельзя отрицать, что писание софта на ассемблере более трудозатратно. но и позволяет делать намного более эффективные вещи.

. вот как раз у интела преемственность архитектуры очень даже хороша.

Ты книжечку-то почитай. Размеры и состав кешей, алгоритмы предвыборки - всё это менялось очень радикально, за исключением последних восьми «поколений», отличающихся друг от друга практически ничем. На не оптимизированном коде оно практически не видно, но если там была глубокая оптимизация, то разница и 20 раз будет, и 50. А если ещё вспомнить о наличии AMD, причём, не только Атлонов, но и Geode (о существовании которых ты как эмбедщища должна знать), то масштаб бедствия становится весьма впечатляющим.

Тут надо ещё понимать, что последняя ошибка - это предпоследняя.

ээээ....а какое отношение к ассемблеру имеет внутренняя архитектура проца? ассемблер как язык с тех пор особо не менялся, надо сказать. появились всякие там дополнительные sse, aes, avx инструкции. и всё.

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

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

Ты почитай книжечку-то. https://www.ozon.ru/context/detail/id/1418882 Либо ты влезаешь в кеш, либо нет. В какой из кешей влезаешь ? Каково время исполнения команды ? Они могут в сотни раз отличаться. Выгодны команды условного перехода или нет ?

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

Это не верно.

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

сколько лет ты работал с ассемблером? теперь своё мнение умножь на это число.

А отличие такого ЯВУ, как сишечка, от ассеблера не такое радикальное, как это преподносят апологеты. Ты еще скажи, щто Кнут устарел.

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

На самом деле, изначально сишечка - это всего лишь макроассемблер для PDP-11.

ну, она обросла библиотеками и на макроассемблер уже какбэ не тянет.