Гений был тот человек, который придумал перепрограммируемый компьютер! Впрочем это не человек, а целая команда инженеров. Но гением точно была она: https://ru.wikipedia.org/wiki/Хоппер,_Грейс
Я о том, что компьютеры не всегда можно было программировать непосредственно кодом. В ранних моделях приходилось долго и нудно физически переподключать блоки проводами. И те, кто придумал составлять программы, гении.
Это очень смелое утверждение особенно что оно охватывает очень широкий круг древних машин которые были довольно разными и выпускались продолжительный период.
У Атанасова была не программируемая машина, соответственно никаких перфокарт там не было. Ещё бы, это ж 30е годы. А на кондерах там хранились промежуточные результаты.
Смотря что подразумевается под "программами для программирования". Если это компилятор - то без ассемблера никак. Если среда разработки - то можно прикрутить существующий компилятор.
Компилятор не написан на ассемблере - он сам пишет на ассемблере. Т.е. разрабы компиляторов пишут на ассемблере только посредством компилятора, но не напрямую.
вы бы хоть загуглили для начала что такое оптимизаторы а что такое компиляторы
и как они стыкуются между собой и для каких целей))
то что прошло компиляцию бессмысленно оптимизировать (хотя есть смысл оптимизировать сам компилятор) но при этом то что прошло оптимизатор вполне себе компилируется
как раз таки сейчас сборшики и многоуровневые
убирают мусор, перестраивают код, присваивают метки и только потом компилируют
С++ в общем-то язык низкого уровня (почти) и вполне справляется с задачами, которые нужно решать на асме. В наше время, когда памяти стало много, то его вполне можно считать языком близким к ассемблеру.
Но таки, асм это основа основ. Знать его не обязательно. Но понимать, как работает система, нужно. Иначе это не очень хороший программист.
Я сейчас не об 1С-никах и питонистах (окей, пайтонистах). Я о тех, кто понимает разницу между компилятором и интерпретатором.
Я сам программист. Исключения лишь подтверждают правило. Нельзя этими примерами опровергнуть основные подходы в языках. Питон - это интерпретируемый язык сценариев и с этим он хорошо справляется. Конечно, наверняка есть извращенцы создавших компилятор для питоновского синтаксиса, но зачем?
Вы сформулировали изначальную фразу - "существование исключения подтверждает существование правила". Согласитесь это не тоже самое, что и (((почему-то))) распространенное в народе "исключение лишь подтверждает правило"
Это не ответ. С таким же успехом я могу заявить, что ни в каком случае не опровергает.
DELETED
Потому что это круто!!!
ещё комментарий
DELETED
Для повышения производительности. Можно просто подключить библиотеку и получить прирост 2-10 раз из воздуха. Ничего не делая, просто импортируя в одном из модулей. А можно воспользоваться компилятором и производительность вырастит еще больше, но там языковые конструкции будут немного другими.
Just In Time (JIT) компиляция. Внутри библиотеки используется кэш с кусками компилированного кода. Первый вызов проходит как обычно, для последующих берется компилированный кусок. Первая была psyco. Я ее лет 10 назад использовал. С тех пор не вникал в эту тему.
Программист, который программирует программы для программирования, программирует на JavaScript! Это один из самых удобных языков на мой взгляд, так как писать на нем можно все - от веб-сайтов и программ, до логики для контроллеров.
А при чём тут VS Code и как он связан с JS? Я не особо с ним работал.
Что же до JavaScript - он не универсален, поскольку он интерпретируемый и высокоуровневый. Вы никогда не сможете написать на JavaScript быстро исполняющуюся низкоуровневую программу. С помощью JavaScript нельзя создать ничего (например компилятора), что работало бы эффективнее самого JavaScript.
и меня то как раз очень бесит что всякие "тру програмисты" с полугодичными курсами за спиной и умением гуглить начинают рассказывать как все языки гавно, то что они не понимают еще большее гавно, а вот то чему их научили на курсах то да, богоугодная хуйня
каждому инструменту свое место
без асемблера вся бы эта навомодная странь бы даже не работала потому как уровень интерпритации
чем меньше промежуток между высоким и низким уровнем тем лучше для быстродействия и оптимизаций
как выше писали, почему go и рвет в плане логики питон - потому что сам интерпритатор на go написан на асемблере, в то время как весь питон от либ до самого ядра в основном на си написан, то есть ему потом еше надо с си в машинный код производить трансформацию
как выше писали, почему go и рвет в плане логики питон - потому что сам интерпритатор на go написан на асемблере, в то время как весь питон от либ до самого ядра в основном на си написан
Вот только результатом работы его программы является ассемблерный код который его программа (компилятор) генерирует на основе программного кода приложения.
Когда программист пишет компилятор он пишет программу для генерации ассемблерного кода.
Ну и что это меняет, зачем фронт/бэк разрабу знать ассемблер? Ну для общего развития можно посмотреть, но асм код сейчас редко используют, обычно для оптимизаций. А программы для программистов это же узкая сфера и всем туда не надо лезть (тут имхо).
Он не нужен до тех пор, пока программист, который программирует программы для программирования не накосячит. А потом ценность программистов, способных понять, куда оптимизатор выкинул инструкции, резко возрастает.
Компиляторы в основном генерируют ассемблерный код, который потом при помощи ассемблера и линкера превращается в обьектный файл, где уже машинный код. К примеру, при запуске gcc(это не компилятор, это toolchain) на сишном файле начнет свою работу cc(это уже С-компилятор), который сгенерирует ассемблерный файл, который потом обработает ld(линкер) и as(gnu-ассемблер) и получится в итоге .o файл (кстати это не полная схема того что делает gcc в этом случае). Слишком дотошно вышло, но, думаю, кому-то такая информация будет полезной.
только не ассемблерный, а промежуточный. Отличие промежуточного кода от ассемблера в том, что промежуточный код уже нельзя просто взять и прочитать, открыв его в блокноте. Так же промежуточный код в отличие от ассемблера является все еще платформонезависимым и одна инструкция байткода может быть транслирована в несколько инструкций процессора, в зависимости от целевой архитектуры
Согласен, но это уже глубокие детали внутренней работы gcc. Но промежуточные состояния платформонезависимые до определенного момента, после чего они уже становятся вполне себе платформозависимыми.
строго говоря, объектный файл содержит не машинный код, а промежуточный, который уже не удобен для чтения человеком, но еще не готов для выполнения машиной
Промежуточный в том плане что отсутствуют ссылки на переменные, методы, классы которые лежат в других модулях. А так-то набор инструкций там не меняется. Компоновщик как раз референсы и проставляет. Насчёт gcc посмотрел, на самом деле делает сначала ассемблерный листинг, а потом уже его транслирует. Наследие с 60х годов. Майкрософт и Борланд так не делают.
А вы упертый)) Вот первоисточник, так сказать от авторов того что вы мне показываете: https://docs.microsoft.com/ru-ru/cpp/build/reference/fa-fa-l... Этот параметр используется как доп опция. Обратите внимание что есть даже ключ который добавит в полученный листинг машинный код, что как бы намекает...
Это параметр который позволяет сохранить этот файл, если он не будет установлен то VS создаст asm файл скормит его ml64.exe и link.exe получит результат и сотрет его за ненадобностью.
Ты отрицаешь очевидно из упрямого нежелания признать что твое первоначальное утверждение было ошибочно.
Не желание признавать свое заблуждение единственный твой мотив.
Под давлением фактов ты бул вынужден признать это в отношении GСС но упорно не желаешь признать это в отношении VS потому что в этом случае вся твоя точка зрения что ты отстаивал превращается в тыкву.
параметр который ты указал это и есть сигнал VS сохранить генерируемый ассемблерный код.
Просто по gcc нашел информацию, а по остальным нет. https://m.habr.com/ru/post/478124/ здесь кстати в комментах этот вопрос тоже обсуждается. Вы бы хоть одну ссылку на источник привели, где бы говорилось что у компилятора vs самоцель сгенерить asm код, а не просто опция.
VS нет цели сгенерировать asm файл, это просто способ генерации машинного кода который позволяет разбить компиляцию на два этапа:
- "эвристический" когда VS анализирует код на ЯВУ с целью сгенерировать максимально эффективный код результат которого она представляет посредством asm файла.
- "механистический" когда ML64 и LINK напрягают все силы чтобы переварить полученный asm файл в исполняемый код.
Такой подход выбран не потому что а ASM это вершина программирования а потому что так можно разбить работу на два этапа а за одно обезличить ЯВУ, то есть VS не важно на C++ или C# или каком другом языке она все их конвертирует в ASM и скормит ML64 и LINK.
Обратите внимание промежуточный результат на asm даже не сохраняется потому что в реальности он никому и не нужен, завтра может выйти обновление по оптимизации, новый сет команд или еще что и VS сгенерирует новый asm по новым правилам.
специально заморочился: поставил студию, снес все ml.exe и ml64.exe. Простейший HelloWorld скомпилировался и запустился и из IDE и из командной строки.
наоборот, за время диалога, я узнал как работает gcc (ни разу с ним не работал, только C++Builder и VS) освежил память в целом по C++ и asm'у (лет 5 наверное их не касался), даже смахнул пыль с очень старого своего проекта.
Искрении рад что общение со мной было для тебя продуктивно, сам же я пока не могу продолжить разговор по данному вопросу потому что мне нужно разобраться почему озвученная тобой ситуация имеет место быть.
Как вариант: код асмотранслятора встроен в сишный компилятор, а асм-листинг создается в оперативке и выгружается в файл только по запросу. Это ускорит процесс компиляции, т.к. нет обращения к диску.
С линкером немного ошибся, бывает на уставшую голову. Но как я уже писал, в том же gcc внутри отдельно создается ассемблерный файл, который потом перерабатывает as в объектный файл. Никто в здравом уме не будет лезть в генерацию машинного кода, когда есть уже проверенные ассемблеры для этого. И кстати, как работают трансляторы я знаю не понаслышке.
DELETED
из чего компилятор делает объектный файл? я просто знаю что ты ошибаешься но хотел бы показать тебе в чем.
из исходников, из кода....*.cpp для с++, *.asm для ассемблера....Ассемблер(транслятор) так же генерит объектные файлы, которые нужно потом собирать линкером. https://habr.com/ru/post/150327 вот кстати хорошая статья о том чем занимается компоновщик
генерация ассемблерного файла из байткода опциональна и нужна для того, чтобы человек мог анализировать программу на этапе генерации промежуточного кода
Вы хотите показать мне, что ваш компилятор умеет генерировать ассемблерный листинг? Но это же не значит что полученные объектные файлы создаются из этого самого листинга.
Опция полезная, не спорю, раньше приходилось дизасемблером пользоваться или отладчиком что бы понять че там накомпилировалось.
Допустим VS генерирует сперва ассемблерный код, а потом скармливает его компилятору в качестве которого она использует ML64.EXE.
Ассемблерный листинг используется как промежуточное звено, вне зависимости от языка программы она переводиться в MASM64, а потом отправляется в ML64.EXE и LINK.EXE и уже они генерируют двоичный код.
чтобы, применяя высокоуровневые конструкции, досконально понимать, что какой-нибудь turbofan (слой логики интерпретатора js v8) из них наинтерпретирует - условно - будет это зиро кост или нихуинушки.
Потому что это такой известный IT срачь. Всех маленьких програмеров сильно мучают в универах заставляя их писать на давно умершем 16-битном асме, в итоге они начинают его люто ненавидеть с религиозной ненавистью.
на диск программа сохраняется в машинном коде... (не в текстовом ;)).. можно сразу запускать.
в редакторе, при загрузке этого файла, видишь удобочитаемые команды
што
как минимум это утверждение ложно по одной простой причине. программа написанная в редакторе может быть некорректна и не собираться. и что в таком случае ваш редактор вам скажет? не могу сохранить ваш бред, сначала почините?
программа на ассемблере это все еще не машинный код.
там есть имена, макросы, и всякое другое.
и если собрать исходный код в машинный и сохранить можно, то обратно ты исходный код уже не получишь "в редакторе".
программа на ассемблере это все еще не машинный код. там есть имена, макросы, и всякое другое.
ну тут уж от редактора зависит, есть конечно и с повышенным комфортом, я пользовался простым, без имён и макросов... или вы имеете ввиду буквенное обозначение регистров?
а переменные и метки это финтифлюшки отдельно взятых редакторов.
если вы программировали на ассемблере явно указывая адреса, мне вас жаль)
надеюсь это была необходимость и отсутствие нормального транслятора под какой-то упоротый микропроцессор.
потому что ассемблер по сравнению с программированием в машинных кодах, помимо мнемоник, как раз снимает головную боль по работе с адресами. когда добавил одну-две команды в середину кода и у тебя все поехало
Компилятор компилирует в машинный код. Ассемблер, это язык для программирования.
Результатом работы программы может являться байт код, а могут быть языки интерпретируемые. В них скомпилированные команды транслируются в машинный код в помощью разных средств.
Программисту не надо писать компилятор, если только он не поддерживает свой язык программирования, или работает в соотвествующей конторе.
По моему, у вас какое-то неверное понимание копм. технологий.
вопросы, какой ассемблер направить в компиллятор ассемблерного кода довольно очевидны. Но для компилляции программ он не обязателен. Стандартный путь это препроцессор - компиллятор - линкер. Препроцессор генерирует промежуточный код, компиллятор транслирует этот код под определенную архитектуру, а линкер соединяет несколько объектных файлов в один исполняемый
промежуточный код, если и генерится, не является ассемблерным. Транслятор Си, по-моему, сразу генерит машинный код. Байткод llvm тоже не совсем ассемблер
IT-юмор
7.1K постов53.2K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору