И почему некоторые языки требуют установки (PHP, Python), а другие - нет (C ++)?
Строгое представление выглядит так.
Компилятор - это просто последовательность двоичных файлов + sr c, как и любой другой программный пакет. Взять, к примеру, Clang или G CC или Rust . В вашей операционной системе вы загружаете исходный код и собираете его. Машинные коды генерируются для вашей конкретной архитектуры процессорного модуля, будь то CPU, GPU или специализированное оборудование.
Похоже, это SRC => BIN. Затем компилятор снова использует себя для сборки своих источников.
SR C => BIN => SR C => BIN2
Возникает вопрос. Если вам требуется компилятор для сборки самого себя, как вы собираете его в первом раунде? Есть одна аккуратная часть вопроса: bootstrapping .
Другой вопрос: как вы решаете, когда остановиться? Вы можете построить свой компилятор под разными углами, ориентируясь на «размер», «скорость» или «время компиляции» или на все это.
Чем хуже компилятор, когда вы просто никогда не собираете его самостоятельно? Да, будет хуже, но в какие сроки? Скорее всего, он будет раздутым, то есть увеличенным размером, и время его компиляции будет больше.
Также есть вещи вне компилятора. Наличие компилятора на Linux означает, что он будет генерировать двоичные файлы ELF, поэтому вам нужен 'libelf'. И это требует, чтобы вы сначала получили определенные библиотеки, а именно 'libatomi c', 'libg cc', 'libstdc ++', 'mpfr', 'gmp', 'coreutils'. Эти библиотеки создают вашу «среду», чтобы вы могли построить следующую итерацию компилятора из предыдущей (в данном случае G CC).
Некоторые языки имеют написанные сами по себе компиляторы, например PyPy. Но первоначальный python компилятор в любом случае потребует, чтобы у вас был C язык для построения начальной версии и среда библиотек.
Программное обеспечение устарело, то есть создаются новые версии библиотек и инструментов, поэтому компиляторы следует регулярно перестраивать из исходных кодов, а те перестраивать всю систему.
Строго говоря, для всех языков требуется «установка», то есть пользователь должен создавать их из источников (Linux) или извлекать коды, необходимые для их конкретный процессор из уже существующего двоичного файла (Microsoft). Или и то и другое, в некоторых случаях (Ubuntu и другие бинарные Linux).
Описанная выше «установка исходного кода» может показаться сложной, но «бинарная установка» на самом деле гораздо сложнее для компиляторов, потому что вы должны проверить окружение, проверьте зависимости, проверьте библиотеки, затем проверьте оборудование, затем извлеките двоичные части, затем перекомпилируйте двоичные части, у которых не может быть одинаковых (x86 против x64) или просто отправьте несколько разных версий одного и того же компилятора для разных архитектур и архитектурных приемов, таких как ELF / Бинарная совместимость WINPE, соглашения о переходе через setjmp и т. Д. c.
PS. Кроме того, сборка вашего компилятора из исходных кодов мешает разработчикам аппаратного обеспечения, как это было с переходом архитектуры x86 -> x86_64. Разработчики оборудования тратят свое драгоценное время не на фактическое улучшение производительности вашего процессора и новых функций, а на поддержку старых наборов команд и обратную совместимость наборов инструкций просто потому, что разработчики программного обеспечения слишком медленно обновляют свои компиляторы. Все это создает огромное «отставание» в системе программно-аппаратного цикла разработки.