LINUX.ORG.RU

Сообщения Dulze

 

Dolphin, копирование, «file://»

При копировании файла и вставке в любое текстовое поле (редактор, браузер) вставляется «file:///home/123/abc.cba». Как автоматически убрать «file://»?

 , , , ,

Dulze ()

ЯП, ОС, архитектура процессоров, инструкции

Заглянув за кулисы своего компьютерного мирка, получил кучу мозаичных кусочков.
1. Вот есть у нас процессор со своей архитектурой, будь то X86 или ARM. Под нее портируют компиляторы топовых языков программирования путем использования процессорных инструкций вроде SSE. Что есть оптимизации компилятора? Вот написан код, компилятор его перековеркал для лучшей производительности на определенной архитектуре при использовании тех или иных инструкций процессора. Но всегда ли выбранный компилятором способ коверканья определенного куска кода можно считать оптимальным? Есть оптимизации на потребление оперативной памяти, производительности, размера кода, да что уж там - всяких «волшебных ключиков» просто тьма, успевай только тестировать их. Обилие этих ключиков соединяются в группы оптимизаций по параметрам. ОС пишут на компиляторе ЯП, компилятор завязан на ОС для компилирования других проектов - иначе не было бы таких разделений вроде: «поддерживаемые платформы: MS Windows, Linux, Android» и т.п. Этот список поддерживаемых платформ есть даже у самого компилятора (rust, например). Вот хочу я, например, свой процессор изобрести с уникальной архитектурой, значит ли это, что мне, минимум, придется портировать компилятор того же С? А если написать операционную систему? Ее корень - ядро, его пишут на ЯП, компилятор которого уже завязан на поддерживаемых им платформах (читай: ОС), значит ли это, что написать свое ядро на том же расте невозможно?
2. Еще мне непонятна идея генерируемого кода компиляторами. Пару слов обо мне: шарпист заинтересовался растом, значит попытаюсь понять на его примере. Так вот, у нас есть компилятор раста, который генерирует безопасный исполняемый код. В том же C или C++ генерируется код, но его безопасность исполнения не гарантируется. В C# есть сборщик мусора как решение проблемы предыдущих языков программирования. В расте сборщика мусора нет, т.е. его компилятором генерируется то же самое, что и у C или C++, но в данном случае он безопасный «на слово», в конечном виде он выглядит как и небезопасный результат компиляторов прежних 2-ух ЯП? Или компилятор раста на стадии компиляции проверяет паршивость кода, но при этом то же самое происходит при выполнении программы и от результата какой-нибудь проверки может случиться что-то иначе? Сложновато объяснил, всё сводится к следующему вопросу: какими жертвами удалось добиться безопасности растом?

 , , , ,

Dulze ()

RSS подписка на новые темы