OberonCore

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

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

Получается, что лучше сделать "среднее" усиление и визуально мониторить уровень записи до -6db,
Но это не точно

Согласен тут с Олегом. Переносимость байт-кодов никак не влияет на переносимость ассемблеров. Это совершенно разные вещи.
И могу добавить, что как-то почитал документацию по Java Embedded (Java Card), это вариант Java для встраивания в кредитные карточки. Так это, грубо-говоря не совсем и Java уже, поскольку, кажется, там выкинуты классы и работа с динамической памятью вообще. Вот, так вот. Не получается "Дом" (в терминологии Олега) запихнуть в кредитку

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

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

Если уж надо всё слинковать, выбросив всё лишнее, тут трансляция в Си действительно уместна.

Мне видется так, что уж если и оптимизировать, то оптимизировать лишь код процедур, сохранив все ареимущества динамической модульности нетронутыми!

И, кстати, оптимизация кода процедур - самая трудоёмкая часть оптимизатора. Поразрезать используемое от неиспользуемого не так сложно!

То есть, слова "любой язык ассемблера переносимый" Вы поняли как "ассемблер - самый переносимый язык", и не знаете, что в этом не так? Да для такой интерпретации нужна могучая фантазия. Соответственно, и эти возражения с PHP, Бейсиком и другими - это результат Вашего внутреннего диалога с неясными для меня цепочками выводов.

Конечно, красота. Я не сказал, где Вы ошиблись и "начал увиливать", потому что излишне оптимистично отнёсся к Вашему умению понимать намёки и элементарно пользоваться поиском в интернете. Конечно же, для Эльбруса была воплощена возможность исполнения кода х86, что было абсолютно закономерно, учитывая распространённость этого машинного языка и отсутствие доступа к исходным кодам многих приложений, которые могут понадобиться пользователям Эльбруса. Об этом сказано во многих материалах по Эльбрусу, например
Есть и видео демонстрации работы в наиболее хардкорном режиме исполнения кода x86.
Нужно было умудриться подобрать такое "опровержение", но Вы смогли. Впрочем, законы жанра подсказывают, что дальше должно произойти новое повышение ставок.

...потому что я не ошибся


Это точно


Похоже, про Эльбрус я знаю больше вас.

По существу что-нибудь будет?
Расскажете как прекрасно Эльбрус эмулирует недокументированные инструкции Intel?

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

Вах, почти выкрутился, придравшись к словам. Но тогда к чему вообще была цитата про то, что где-то используются две похожих архитектуры? Взяли бы, да и пояснили свою точку зрения сразу. А если Вы взялись спорить про аппаратную поддержку систем команд Intel x86 и AMD x64 в Эльбрусах, то почему увиливаете с темы эмуляторов? На Эльбрусе можно запустить точный эмулятор x86, который точно убьёт все преимущества от использования Эльбруса. Будет очень качественная переносимость.

Так что я с Вами тут готов поспорить. Берём Вашу фразу "любой язык ассемблера переносимый" и применяем её в контексте "язык ассемблера AMD 64 (ибо прозвучало слово "любой") переносимый на, скажем, Arduino". Или Вы должны были пояснить свою мысль, что у такой "переносимости" есть один крайне важный недостаток — она работает только в сторону "более слабая архитектура на более сильную", да и то не всегда. Можно придумать специфические условия, где это не сработает.

Вы ещё порассуждайте о целесообразности такой переносимости. Да. Всё можно сэмулировать на всём, если ресурсов хватит. Лишь бы в этом был какой-то смысл. Но это не переносимость, в моём понимании. Эмуляция — это вымученный подход борьбы с фрагментацией, имеющий очень много недостатков. А с точки зрения простоты это лишние слои-посредники. И производительность слой такой "переносимости" убивает. А её нужно экономить, чтобы хватило для ресурсоёмких задач.

Break!!!

Вот это зря - какая именно ардуина? Бывает на AVR (8 бит, RISC настоящий), а бывает на CortexM0 (32 бита и RISC, скажем так, таковым когда-то бывший). "Похожа свинья на Ёжа"

Fight!!! (-;

Так же как и AMD (тоже пример "непереносимости", который у всех перед носом). В идеале - никак. Исполнители машинных языков, также как и трансляторы высокоуровневых языков и разнообразных промежуточный представлений могут содержать как ошибки, так и сознательные недокументированные возможности, это не откровение. Но нужно плохо разбираться в вопросе, чтобы 1) считать это особенностью именно машинных языков 2) требовать безусловного повторения чужих дыр. В большинстве случаев считается за благо отсутствие подобных вещей. А то, ведь, можно потребовать и воплощения "Meltdown", "Spectre" и "Spoiler".

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

Константин, вы перегибаете палку. В первом сообщении Валеры вполне понятно что он имел в виду под метафорой "переносимый ассемблер". Это точно не то, что вы понимаете под переносимостью. И непонятно, зачем дальше гнуть свою линию, если это явно никому не надо. Это просто мимо темы получилось по итогу.

Си - на сегодняшний день один из наиболее доступных способов для нас организовать то, чтобы единожды написанный код на Обероне-2 работал без виртуализации на разных платформах без внесения значительных переделок. Ну и если обычно компилятор выдает по итогу своей работы сложнопереносимый машинный код (в метафоре это называется "ассемблер"), то у трансляторов типа Офронта или Восток на выходе — Си, который более или менее компилируется на разных платформах. Вот и получается "переносимый ассемблер". У вас эта метафора явно какие-то другие ассоциации вызывает. Это и не хорошо и не плохо... но лучше, когда взаимопонимание.

Отлично. Закрыли тему!

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

Повторю, "Си - переносимый ассемблер" - это манипуляция, иными словами - "это опасная аналогия, которая может привести к неверным выводам", и что характерно, приводит.

Да и из сообщения Сергея Волкова была понятна суть метафоры, и в своём 1-м сообщении я огласил суть кривизны этой аналогии. Про аналогию Си, как ассемблера для UNIX - это тоже обычное натягивание совы на глобус. Тут уровень мышления - раз мы знаем, что ОС пишется на языке ассемблера, а UNIX была переписана на Си(сначала она была переписана на Би), то Си(или Би) - это типа ассемблер, тока переносимый. Но в том, что ОС можно писать на ЯВУ нет ничего удивительного. ОС Multics, являющейся прямой вдохновительницой UNIX, была написана на выскоуровневом языке PL/I, но даже она не была в этом 1-й. Предположу, что сами авторы UNIX не пользовались ассемблерной аналогией хотя бы поэтому.

Более того, я привёл ссылку на доклад, в котором затрагивается работа Кена Томпсона, связанная с ассемблером NS3200, который был доработан до переносимости и в конечном итоге был положен в основу ассемблера Go. Идея этой работы понятна? Правильный ли в ней ассемблер? Точно такая ли там переносимость как я понимаю или точно не такая? Возможна ли применимость этих результатов к другим ассемблерам или это неповторимый результат?
Если не получается мыслить абстрактно, то, может, хотя бы посмотреть на разные работы? Их ещё много.

Мне задали вопрос по одному из пунктов, я ответил. Хотя мы в теме по Радио Оберон, но слова нужны не только для того, чтобы просто потрепаться. В первую очередь это важный инструмент, от корректности которого многое зависит.

Я уже много раз писал, что транслятор проекта Восток не является транслятором в Си. Это многоцелевой транслятор, на данный момент поддерживающий 3-и почти равноправных выходных языка, каждый из которых позволяет получить рабочую версию транслятора. Как минимум 2-а языка позволяют получить желаемый многими машинный код. Возможность трансляции обеспечивается тем, что все эти языки алгоритмически полны (полны по Тьюрингу), но ни один из ныне поддерживаемых не является языком ассемблера. Я бы не стал добавлять другие выходные языки, если бы мыслил аналогией "переносимого ассемблера".

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

Я всегда считал, что появление для С ярлыка "переносимый ассемблер" связано не с тем, что "ОС с ассемблера переписали на нём" (т.е. смысл фразы не "Си - крутое новое слово в написании ОС"), а как раз с тем, что к тому моменту уже были хорошие практики написания ОС на ЯВУ.
А тут некий недоЯВУ. Ну и получается, что он по уровню и удалению от машины не сильно от ассемблера ушёл, и единственный плюс - таки большая переносимость. Т.е. язык "получше ассемблера, но недоЯВУ".

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

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

Вот лучше приходите рассказать про Восток на радиопередачу?!

Я употребил слово "переписана" не потому что я считаю, что для переносимости нужно переписывать, а только потому, что ОС UNIX не была сразу написана на Си, а был переписана для этого как минимум 2-а раза.

Багаж знаний нужен для указания на примеры, для понимания сути достаточно понимания полноты по Тьюрингу. Наверно, достаточно.

Мне не подходит формат радиопередачи. Я бы и с тем, что записано в "Радио Оберон" предпочёл бы ознакамливаться в виде текста.

Да, у вас хороший блог: https://comdivbyzero.blogspot.com
Формат подкастов весьма специфический. Это целая культура. Пока не познакомитесь с какими-нибудь достойными образцами подкастов, то и не загоритесь, конечно.
Мне нравится формат подкаста тем, что это всё-таки беседа. Во время беседы мысли рождаются легко. Когда пишешь текст, то мысли рождаются в муках переписывания

Конечный продукт -- это всё-таки текст, а не звук.

Звук не особо пролистаешь.