Два режима понятно, но накладно. То есть переключаясь в режим отладки, мы получаем другой машинный код, что уже может повлечь за собой какие-то различия в исполнении. Вопрос у меня скорее в другом. Как будут работать эти отладочные символы, про которые Вы говорите? На стороне IDE есть только инструкции байткода, и их соответствие с языком верхнего уровня. В runtime уже появляется две сущности, одна это оригинальный байткод, другая это исполняемый код. Как Вы предполагаете осуществлять работу, для начала, точек останова?
Это сейчас одно и моих направлений, нужно выбирать за основу какой-то вариант реализации. При этом скорость исполнения на первом месте, именно поэтому читаю и смотрю варианты с пред-компиляцией.
Разве, если делать такие вставки, то не придется ли слишком много прыгать?
Пробовал, частично, в виде тестов. Этот подход неплохой как компромисс, но проблема у меня в методе отладки при таком подходе. Если с обычным байткодом отладка реализуема и понятна, то при переводе в машинные коды пока не увидел адекватного решения.
Я подразумевал не полную компиляцию всего и вся в единую бинарную программу. А компилировать только тела функций, набрасывая ассемблерные команды по шаблону на каждую из них. Пуская с nop выравниванием и оригинальными вызовами функций. В одном теле не так много переходов, чтобы оно «распухало» при переводе в ассемблерный вид. Хотя конечно не спорю, в больших программах потребуется время на подготовку.
А почему рассматривался именно динамический JIT? Можно ведь при старте программы распаковывать ее транслируя в нативные инструкции, пусть и без хитрых оптимизаций.
Возьмите светодиодную ленту, включите на требуемую яркость при комнатной температуре, измерьте температуру светодиодной ленты через час. Полученную разницу температуры между воздухом и лентой прибавьте к температуре воздуха в бане. Если она превышает допустимую для светодиодов, то работоспособность ленты будет зависеть от святого духа. Это конечно очень грубый расчет, к тому же стоит учитывать изоляцию между лентой и баней, которая, возможно, сместит рабочую температуру.
Нужен пример из реальных и больших задач/проектов. Сколько помню, всегда приводят в пример миганием светодиодом или обращение к IO пинам — это не показатель.
Про рекламу я понимаю, но как высказался еще один собеседник внизу — просто рекламу читать не интересно. Вопрос в следующем, как мне проверить, что ваш протокол RPL действительно надежный и безопасный? Можно опустить про надежность, но то, что он закрыт от посторонних глаз не говорит о безопасности. Сейчас это довольно актуально. В целом протоколы сейчас строятся на более-менее одинаковых принципах, главное чтобы все было на месте.
Уже как-то задавал вопрос к прошлой статье, но, увы, остался без ответа. Не хватает технических подробностей. Здесь Вы упомянули про собственный протокол RPL, где можно посмотреть его спецификацию и описание?
Не совсем понимаю, как ломают принтер? В моем понимании там стоит встраиваемая система, возможно даже без RTOS, с простым стеком для сети, что там можно сломать?
Не хватает технических деталей. Как разрабатывали и тестировали встроенное ПО? Как тестировали железо в серии? С какими проблемами столкнулись и как их решили? А то «здесь процессор, здесь батарейка» выглядит как плохо подготовленный доклад
Честно говоря, для человека который «не в теме» здесь текст похож на какие-то общие слова без какой-либо детализации. Смахивает на мыльную статью для тематического журнала, уж простите. Хотелось бы больше подробностей, кода, примеров использования, сравнения производительности.
Разве, если делать такие вставки, то не придется ли слишком много прыгать?