Ещё раз. Ваша задача — показать мне валидатор utf16. Вы утверждали обратное.
Далее, все эти рассуждения — сотрясение воздуха. Вы утверждали, что в строках должен быть валидатор utf8, либо там мусор. Теперь вы либо должны это доказать. Никакое отсутствие/присутствие валидации никакого отношения к теме не имеет.
Повторю ещё раз. Валидатор utf16, а так же доказательства того, что «только валидированный utf8 является строкой». А так же, что меня вообще в какой-то мере должна волновать какая-то валидация, но это уже другая история и на неё можно не отвечать.
Пока вы не провалидировали набор байт — у вас набор байт,
Полная чушь. Вы опять показываете свою полную несостоятельность. Никакой валидации utf16 не требует, я специально упомянул именно его, что-бы в очередной раз доказать ваш уровень понимания темы.
Ещё раз. Вы сказали, что всё что не utf8(всё во что не может ваша «строка») — мусор. Вернее мусор всё то, что не понимают строки в вашем супер-языке сливающему lua. И я даже не буду рассказывать, что никакой строке вообще никакая валидация/utf8 ненужны.
У вас два варианта. Либо продолжать отрицать очевидное(что строки и utf8 являются синонимом), либо признать ошибку.
У меня возникает такой вопрос, почему каждая ваша попытка со мною спорить — заканчивается полным вашим поражением?
В Rust строки — это utf-8 строки (байтовый массив + проверка на utf-8-корректность последовательности байт).
Мне какая разница с этого? Меня начали уверять, что строки такими «и должны быть» — я на это отвечал. Они такими быть не должны.
Если нужны какие-то иные строки, используется байтовый массив без проверок.
Мне никакой rust и никакие его строки использовать ненужно. Зачем вы мне это пишите? Вы это пишите тем, кто оправдывал этим малую производительность раста. Пусть они их используют и, возможно(крайне маловероятно) перестанут сливать lua.
Со всем остальным будет тоже самое. Так было с машинами, ir и прочими аллокаторами.
Вот примеры ЦПУ способных выполнять JVM байткод напрямую,
Нет. Но мы пока опустим это. Начнём с вопроса простого:
Такая же история есть с java-байткодом в каких-нибудь arm.
Все эти ухищрения неэффективны. Именно поэтому они и умерли, а существовали только на начальных этапах. Как в том же arm. Исполнитель откровенно слаб, частота маленькая. Проще туда впихнуть побольше всякой логики и будет быстрее. Но чем дальше — тем хуже.
На каком основании вы мне 1) показываете как контр-аргумент моим утверждения то, о чём я заранее и до вас сказал. 2) почему были проигнорированы мои объяснения по этому поводу?
К тому же я не вижу от вас доказательств, что эти накиданные вами ссылки из википедии действительно исполняют jvm-байткод(весь) и целиком и полностью имплементируют jvm хардварно.
Не допустим. Это так и есть. Это мною доказано, как и доказано враньё с вашей стороны.
Вывод из этого очень просто, вы врали(ошибались) когда говорили, что rustc каким-то образом сам генерирует ir. С этим тезис я спорил. Его я опроверг.
Вам так приятно, что софтина на плюсах написана?
Ну почему же. Мне это неприятно, наоборот. Но в основном мне неприятно вранье и клоунада. Уровень и методику спора своих оппонентов я знаю. И доказать мне это не составляет труда.
Именно поэтому я могу доказывать, я могу выигрывать. Вы можете врать и гадить в карму/минусовать комменты.
Я даже не знаю зачем я начал спор с вами. Это глупо. В конечном итоге мне тут смог оппонировать только один человек. Радует, что хоть один есть. Посоветовать могу только одно. Больше знать/уметь и меньше заниматься спорами без знаний/умения.
Раст изначально написан на окамле,
Никакой раст не был написан на окамле. Это глупость. То, что оно называлось «rust» это не значит, что тот «rust» был сегодняшним rust.
должно ли окамловцам быть приятно?
Да нет. Наоборот. Rust тогда ничего из себя не представлял. А вот когда ушел к llvm. Но уже совершенно другая история.
Должны ли они себя бить в грудь, что раст-то говорят не настоящий?
Я не знаю кто что должен. Я знаю, что врать/утверждать не зная — плохо. Вы начали рассказывать всем, что rust может генерировать ir. Это ложь. Это я знаю. Остальное мне не интересно.
IR является платформо-зависимым во многих аспектах. Он достаточно сложен. Именно поэтому никакой фронт его не генерирует.
llvm предоставляет api, который и занимается генерацией ir. Именно этот api использует rustc и любой другой фронт. Я даже больше скажу. Сам llvm знает про раст. Без поддержки llvm никакой фронт существовать не может.
Тем же самым занимается clang, который тоже является компилятором. И не потому, что он компилирует си.
Зачем вы ссылаетесь на clang? К чему это? Вы утверждали, что код на rust сам генерирует ir. Это неправда. В ситуации с clang это не работает. Да, тут так же ir генерирует llvm, но llvm написан на С++, а значит С++ генерирует для себя ir. И неважно где этот код лежит.
К тому же, clang это неотъемлемая часть llvm. rustc же внешняя часть.
Вы ссылки выше прочитайте. Вон процессоры, выполняющие байткод.
Ещё раз, байткод не жава. Зачем я повторю одно и тоже, одно и тоже тому, что попросту всё неудобное игнорирует и повторяет одни и те же фразы, на которые же был дан ответ.
А я этого не говорил. Перечитайте фразу «генерирует х86, исполняемый нативно»
Ложь.
Есть лисп-машины, с тем же успехом можно сделать процессор, выполняющий net код. Что дальше?
Говорилось именно про высокоуровневые языки и их байткод(хотя причём тут тогда лисп-машины?).
Если же говорить о компиляторе как о программе, преобразующий исходный код в исполняемые файлы, вдруг окажется, что csc — не компилятор.
Т.е. вы уже сами себя опровергли, т.к. доказали изначальный тезис автора. Что для того, что-бы java-байткод был нативным — должен быть нативный его исполнитель. Очевидно, что вы тут тоже пытаетесь подменить понятия, т.к. javame не является java.
Мой же тезис заключался в том, что 1) нативные реализации байткод/лист-акселераторов существуют. Я это сказал изначально. 2) они ненужны и несостоятельны в общем контексте. Это всё применяется на слабом железе, причём применяется редко и никак вверх не скалируется. Именно поэтому этого никогда за пределами примитивной логики не будет.
К тому же, зачастую во всех эти байткод-акселераторах применяется обычная бинарная трансляция. Т.е. реальная архитектура железки иная. Она не исполняет напрямую байткод, а просто транслирует байткод в некий набор обычных инструкций.
Делается это потому, что транслировать байткод софтварно дорого и непредсказуемо. Поэтому в подобных слабых(и)реалтайм решениях это может иметь(и имеет) какой-то смысл.
Ничего из этого вы не опровергли. Вы начала мне кидать ссылки из википедии. Абсолютно непонятно зачем, ведь я ещё до вас вам сообщил, что подобные решения есть.
Давайте я вам скину MIR, а вы с помощью LLVM попробуете из него получить LLVM IR? Спойлер, у вас не выйдет, потому что это просто не так.
Давайте мы поступим проще. Вы берёте rustc без llvm и генерируете ir. Если ваши рассуждения верны — вы сможете это сделать, ведь вы утверждали, что «rustc САМ(т.е. средствами кода написанного на rust) генерирует что-то там(как я понял — это IR)». Если сам — сгенерируйте.
К тому же, зачем вы продолжаете повторять глупости про mir и игнорируете все мои контр-аргументы? Из того, что llvm не умеет mir не следует, что rustc умеет генерировать(сам) ir. Это очевидно.
Java — нативный язык, потому что генерирует JVM, исполняемый нативно.
Неверно. Нельзя генерировать jvm, да если имеет ввиду байткод, то байткод никто исполнять не умеет. Я уже говорил, что это embedded java, а не обычная Java. И она целиком и полностью несостоятельна для решения прикладных задач.
С++ — нативный язык, потому что генерирует x86, исполняемый нативно
С++ не может исполняться. Именно об этом говорилось. Подобная формулировка вообще не имеет смысла, т.к. любой язык так или иначе преобразуется в нативный код. И именно нативный код исполняется.
Под нативным в контексте С++ имеется ввиду не то, что он преобразуется в нативный код, а в том что он исполняется нативном на платформе. И противопоставляется это языкам, которые требуют эмуляции платформы. Это называется vm. Именно поэтому то, что исполняется в jvm по определению не может является нативным платформе.
Так же, все эти рассуждения вообще не имеют смысла т.к. никаких хардварных исполнителей байткода не существует. Всё что существует — не является системами/языками общего назначения и вообще находится вне контекста. На этом уже можно закончить.
Ведь я сразу это обозначил. Что на уровне примитивных исполнителей имеет смысл пихать что-то в железо. Но мы, в том числе и я, не обсуждаем тут примитивное/узкоспециализированное железо.
Опять попытка смерить тему, но неудачная. Про жава-байткод я уже говорил:
Просто хардварные оптимизации характерные для lisp. Такая же история есть с java-байткодом в каких-нибудь arm.
Так же я там говорил и про причины их появления. Все эти ссылки из википедии — целиком и полностью ложатся на моё описание.
По поводу самого «опровержения».
JVM байткод напрямую, для которых Java — нативный язык.
Это полная чушь. java и jvm-байткод это разные вещи. Далее видна попытка дёргать фразы из контекста, хотя я уточнял:
Никаких следов существования чего-либо кроме, либо существования каких-либо исполнителей высокоуровневых языков, не существовало и не существует. И даже если теоретически это сделать можно — это делать бесполезно.
jvm-байткод не является java, не является высокоуровневым языком. Так же требует компилятора/транслятора.
Так же, такого понятия как java вообще не существует. Существует много версий всяких разных java. И та java, которая используется в embedded — это совершенно другая жава(https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition).
Про эти акселераторы байткода я уже писал. Это существует только на уровне примитивной логики и ничего не умеет. Они не обладают какой-либо производительностью. Они не могут исполнять обычный jvm-байткод.
Допустим. Какой из этого вывод? Какая польза от этого утверждения? На этом этапе вообще никаких языков нет, ни сипипи, ни хаскеля.
Очень простой вывод.
Изначальный ваш тезис:
Есть лисп-машины, с тем же успехом можно сделать процессор, выполняющий net код. Что дальше?
Я, конечно же, опроверг существование лисп-машин(в том виде, в котором декларировали их вы). Опроверг состоятельность попыток реализовать процессор выполняющий lisp/.net и вообще чего угодно. Мир не знает подобных примеров, а все попытки расширять даже архитектуру(привет циск) потерпели неудачу.
Я подтвердил это:
я бы назвал «исполняемым» «исполняемый процессором» код, а всё остальное — интерпретируемым.
Т.е. исполняемым может быть только нативный код. Нативный в привычном смысле. Никаких следов существования чего-либо кроме, либо существования каких-либо исполнителей высокоуровневых языков, не существовало и не существует. И даже если теоретически это сделать можно — это делать бесполезно.
llvm. Я уже отвечал на это. llvm-ir генерирует llvm-логика, которая написана не на расте. Далее эту внешнюю логику раст использует через биндинги. Так работает любой llvm-фронтенд.
Эти рассуждения вообще не имеют смысла, ведь rustc попросту слинкован с llvm и без него в принципе существовать не может. Ваше утверждение изначально ложно. Но я пошел вам навстречу и говорю о том, что может(гипотетически) rustc в отрыве от llvm. Может он только генерировать mir(возможно ещё какие-то подобные промежуточные представления).
Компилятор Rust написан на Rust
Начальный тезис был, все рассуждения ведутся в этом контексте. Вы так же на это явно указывали.
Я думаю вы знаете, что из одного языка можно вызвать логику на другом языке. Именно таким механизмом пользуется rust.
То есть LLVM понимает MIR, раз уж раст после него ничего не генерирует? Вот так новость.
Эту глупость, а не новость. Я уже всё объяснял. llvm предоставляет api для генерации ir. Если мы берём те части, которые в rustc написаны на rust(а именно об этом шла речь), то они никак не генерируют ir. Они используют хайлевел llvm-api через биндинги.
Повторю ещё раз. Те части, которые в rustc написаны на rust могут генерировать ТОЛЬКО mir. Из этого факта никак не следует, что llvm должен начать понимать mir.
Нет. Контекст был «на rust». rustc не генерирует ir — его генерирует llvm.
В процессе этой генерации он внутри себя проходит через промежуточное представление MIR.
Я уже это говорил. mir — это единственное, что генерирует rustc сам. Вы утверждали, что rustc является компилятором(транслятором) во что-то там. Вы не уточняли во что именно он транслируется(понятно что в ir).
И вот, когда вы знаете, что rustc(сам) генерирует только mir. Таким образом отсюда:
Да нет, весь компилятор. Никто не говорит, что таргетом компилятора должен быть машинный код.
Может следовать только «таргет == mir». Почему mir не может являться и таргетом и промежуточным представлениям понятно.
Таким образом я доказал, что ваше утверждение некорректно и не имеет смысла.
И да, хамить в комментах последнее дело.
Конкретика. Где «хамить» и в чём «хамить» заключается.
Ну ок, допустим не является. Дальше что? Какие из этого практические выводы полезные сделать можно?
Выводы я сделал выше. Я опроверг ваши наивные рассуждения про lisp-машины. Я опроверг ваши рассуждения про «можно сделать какой угодно исполнитель». Нельзя. Этим никто не будет заниматься. Это практический вывод.
От того что v8 является эффективным софтом на плюсах электрон не стал эффективным.
Из этого ничего не следует. Разговор был о хардварных исполнителях. Я вам дал возможность подменить тему на софтварные исполнители. В очередной раз подменить тему я вам не дам.
Можно посмотреть на слак который гигабайты отжирает там, где телеграм обходится десятками мегабайт.
Какое это имеет отношение к теме? Мы не обсуждали исполняемый код, а обсуждали исполнитель.
Даже больше скажу. Я утверждал(и именно об этом я говорил), что исполнитель под «неэффективно» нельзя сделать эффективно. Это одно из следствий. И даже непросто «сделать эффективно» просто «сделать» нельзя.
А то можно дойти до того, что «весь код выполняется на процессоре, вылизанным десятками гениальных инженеров интела, значит весь код эффективный».
Если бы вы почитали, зачем MIR вообще придумали, то увидели бы, что это сделано для более простых и глобальных оптимизаций и некоторых других вещей.
Пруфы. К тому же, что вообще из этого следует? Я опроверг ваши рассуждения. Абсолютно неважно то, чем является mir. Таргетом в rustc может является только он, ведь только его генерирует rustc сам.
Что насчет «внутренних представлений», то етсь такая штука, как абстракция, и они как матрешки нанизываюстя друг на друга.
Это набор слов. Узнайте значение понятия «таргет». Внутреннее представление, либо промежуточное представление — это по определению то, что находится до таргета. Если бы оно было таргетом — оно бы не называлось промежуточным/внутренним.
Есть HAL, который абстрагирует ОС, которую абстрагирует clib, которую абстрагирует фреймворк, который абстрагирует...
И? Я вас где-то спрашивал про «что такое промежуточное представление»? Я вас где-то спрашивал про «что такое абстракции»? Нет и нет. Зачем вы мне это пишите?
Вы пытались сказать, что в rustc rust-код генерирует ir. Это неправда. Вам нужно на это отвечать.
Далее, все эти рассуждения — сотрясение воздуха. Вы утверждали, что в строках должен быть валидатор utf8, либо там мусор. Теперь вы либо должны это доказать. Никакое отсутствие/присутствие валидации никакого отношения к теме не имеет.
Повторю ещё раз. Валидатор utf16, а так же доказательства того, что «только валидированный utf8 является строкой». А так же, что меня вообще в какой-то мере должна волновать какая-то валидация, но это уже другая история и на неё можно не отвечать.
Полная чушь. Вы опять показываете свою полную несостоятельность. Никакой валидации utf16 не требует, я специально упомянул именно его, что-бы в очередной раз доказать ваш уровень понимания темы.
Ещё раз. Вы сказали, что всё что не utf8(всё во что не может ваша «строка») — мусор. Вернее мусор всё то, что не понимают строки в вашем супер-языке сливающему lua. И я даже не буду рассказывать, что никакой строке вообще никакая валидация/utf8 ненужны.
У вас два варианта. Либо продолжать отрицать очевидное(что строки и utf8 являются синонимом), либо признать ошибку.
У меня возникает такой вопрос, почему каждая ваша попытка со мною спорить — заканчивается полным вашим поражением?
Мне какая разница с этого? Меня начали уверять, что строки такими «и должны быть» — я на это отвечал. Они такими быть не должны.
Мне никакой rust и никакие его строки использовать ненужно. Зачем вы мне это пишите? Вы это пишите тем, кто оправдывал этим малую производительность раста. Пусть они их используют и, возможно(крайне маловероятно) перестанут сливать lua.
Со всем остальным будет тоже самое. Так было с машинами, ir и прочими аллокаторами.
Нет. Но мы пока опустим это. Начнём с вопроса простого:
На каком основании вы мне 1) показываете как контр-аргумент моим утверждения то, о чём я заранее и до вас сказал. 2) почему были проигнорированы мои объяснения по этому поводу?
К тому же я не вижу от вас доказательств, что эти накиданные вами ссылки из википедии действительно исполняют jvm-байткод(весь) и целиком и полностью имплементируют jvm хардварно.
Не допустим. Это так и есть. Это мною доказано, как и доказано враньё с вашей стороны.
Вывод из этого очень просто, вы врали(ошибались) когда говорили, что rustc каким-то образом сам генерирует ir. С этим тезис я спорил. Его я опроверг.
Ну почему же. Мне это неприятно, наоборот. Но в основном мне неприятно вранье и клоунада. Уровень и методику спора своих оппонентов я знаю. И доказать мне это не составляет труда.
Именно поэтому я могу доказывать, я могу выигрывать. Вы можете врать и гадить в карму/минусовать комменты.
Я даже не знаю зачем я начал спор с вами. Это глупо. В конечном итоге мне тут смог оппонировать только один человек. Радует, что хоть один есть. Посоветовать могу только одно. Больше знать/уметь и меньше заниматься спорами без знаний/умения.
Никакой раст не был написан на окамле. Это глупость. То, что оно называлось «rust» это не значит, что тот «rust» был сегодняшним rust.
Да нет. Наоборот. Rust тогда ничего из себя не представлял. А вот когда ушел к llvm. Но уже совершенно другая история.
Я не знаю кто что должен. Я знаю, что врать/утверждать не зная — плохо. Вы начали рассказывать всем, что rust может генерировать ir. Это ложь. Это я знаю. Остальное мне не интересно.
Покажите мне машину, которая исполняет лисп.
Покажите. Где? То, что вы там линкуете — генерирует rustc, который слинкован с llvm. Вам нужно убрать оттуда llvm и сгенерировать ir.
Нет. Это глупость.
Неверно. Никакой раст никакой ir не генерирует. раст занимается вызовов llvm-api, который генерирует ir. Именно llvm генерирует ir.
Я вам советую изучить тему перед тем как что-то утверждать. Начините отсюда github.com/rust-lang/rust/tree/master/src/rustllvm Далее github.com/rust-lang/rust/tree/master/src/librustc_codegen_llvm который напрямую забинден с rustllvm.
Нет, вы не изучали вопрос. Изучите.
IR является платформо-зависимым во многих аспектах. Он достаточно сложен. Именно поэтому никакой фронт его не генерирует.
llvm предоставляет api, который и занимается генерацией ir. Именно этот api использует rustc и любой другой фронт. Я даже больше скажу. Сам llvm знает про раст. Без поддержки llvm никакой фронт существовать не может.
Зачем вы ссылаетесь на clang? К чему это? Вы утверждали, что код на rust сам генерирует ir. Это неправда. В ситуации с clang это не работает. Да, тут так же ir генерирует llvm, но llvm написан на С++, а значит С++ генерирует для себя ir. И неважно где этот код лежит.
К тому же, clang это неотъемлемая часть llvm. rustc же внешняя часть.
Ещё раз, байткод не жава. Зачем я повторю одно и тоже, одно и тоже тому, что попросту всё неудобное игнорирует и повторяет одни и те же фразы, на которые же был дан ответ.
Ложь.
Говорилось именно про высокоуровневые языки и их байткод(хотя причём тут тогда лисп-машины?).
Т.е. вы уже сами себя опровергли, т.к. доказали изначальный тезис автора. Что для того, что-бы java-байткод был нативным — должен быть нативный его исполнитель. Очевидно, что вы тут тоже пытаетесь подменить понятия, т.к. javame не является java.
Мой же тезис заключался в том, что 1) нативные реализации байткод/лист-акселераторов существуют. Я это сказал изначально. 2) они ненужны и несостоятельны в общем контексте. Это всё применяется на слабом железе, причём применяется редко и никак вверх не скалируется. Именно поэтому этого никогда за пределами примитивной логики не будет.
К тому же, зачастую во всех эти байткод-акселераторах применяется обычная бинарная трансляция. Т.е. реальная архитектура железки иная. Она не исполняет напрямую байткод, а просто транслирует байткод в некий набор обычных инструкций.
Делается это потому, что транслировать байткод софтварно дорого и непредсказуемо. Поэтому в подобных слабых(и)реалтайм решениях это может иметь(и имеет) какой-то смысл.
Ничего из этого вы не опровергли. Вы начала мне кидать ссылки из википедии. Абсолютно непонятно зачем, ведь я ещё до вас вам сообщил, что подобные решения есть.
Давайте мы поступим проще. Вы берёте rustc без llvm и генерируете ir. Если ваши рассуждения верны — вы сможете это сделать, ведь вы утверждали, что «rustc САМ(т.е. средствами кода написанного на rust) генерирует что-то там(как я понял — это IR)». Если сам — сгенерируйте.
К тому же, зачем вы продолжаете повторять глупости про mir и игнорируете все мои контр-аргументы? Из того, что llvm не умеет mir не следует, что rustc умеет генерировать(сам) ir. Это очевидно.
Неверно. Нельзя генерировать jvm, да если имеет ввиду байткод, то байткод никто исполнять не умеет. Я уже говорил, что это embedded java, а не обычная Java. И она целиком и полностью несостоятельна для решения прикладных задач.
С++ не может исполняться. Именно об этом говорилось. Подобная формулировка вообще не имеет смысла, т.к. любой язык так или иначе преобразуется в нативный код. И именно нативный код исполняется.
Под нативным в контексте С++ имеется ввиду не то, что он преобразуется в нативный код, а в том что он исполняется нативном на платформе. И противопоставляется это языкам, которые требуют эмуляции платформы. Это называется vm. Именно поэтому то, что исполняется в jvm по определению не может является нативным платформе.
Так же, все эти рассуждения вообще не имеют смысла т.к. никаких хардварных исполнителей байткода не существует. Всё что существует — не является системами/языками общего назначения и вообще находится вне контекста. На этом уже можно закончить.
Ведь я сразу это обозначил. Что на уровне примитивных исполнителей имеет смысл пихать что-то в железо. Но мы, в том числе и я, не обсуждаем тут примитивное/узкоспециализированное железо.
Так же я там говорил и про причины их появления. Все эти ссылки из википедии — целиком и полностью ложатся на моё описание.
По поводу самого «опровержения».
Это полная чушь. java и jvm-байткод это разные вещи. Далее видна попытка дёргать фразы из контекста, хотя я уточнял:
jvm-байткод не является java, не является высокоуровневым языком. Так же требует компилятора/транслятора.
Так же, такого понятия как java вообще не существует. Существует много версий всяких разных java. И та java, которая используется в embedded — это совершенно другая жава(https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition).
Про эти акселераторы байткода я уже писал. Это существует только на уровне примитивной логики и ничего не умеет. Они не обладают какой-либо производительностью. Они не могут исполнять обычный jvm-байткод.
Нет, и это очевидно.
Очень простой вывод.
Изначальный ваш тезис:
Я, конечно же, опроверг существование лисп-машин(в том виде, в котором декларировали их вы). Опроверг состоятельность попыток реализовать процессор выполняющий lisp/.net и вообще чего угодно. Мир не знает подобных примеров, а все попытки расширять даже архитектуру(привет циск) потерпели неудачу.
Я подтвердил это:
Т.е. исполняемым может быть только нативный код. Нативный в привычном смысле. Никаких следов существования чего-либо кроме, либо существования каких-либо исполнителей высокоуровневых языков, не существовало и не существует. И даже если теоретически это сделать можно — это делать бесполезно.
В чём наезд?
llvm. Я уже отвечал на это. llvm-ir генерирует llvm-логика, которая написана не на расте. Далее эту внешнюю логику раст использует через биндинги. Так работает любой llvm-фронтенд.
Эти рассуждения вообще не имеют смысла, ведь rustc попросту слинкован с llvm и без него в принципе существовать не может. Ваше утверждение изначально ложно. Но я пошел вам навстречу и говорю о том, что может(гипотетически) rustc в отрыве от llvm. Может он только генерировать mir(возможно ещё какие-то подобные промежуточные представления).
Начальный тезис был, все рассуждения ведутся в этом контексте. Вы так же на это явно указывали.
Я думаю вы знаете, что из одного языка можно вызвать логику на другом языке. Именно таким механизмом пользуется rust.
На этом этапе раста уже нет.
Это я пошел вам на встречу, а мог бы закончить на факапе с lisp-машинами.
Только mir.
Эту глупость, а не новость. Я уже всё объяснял. llvm предоставляет api для генерации ir. Если мы берём те части, которые в rustc написаны на rust(а именно об этом шла речь), то они никак не генерируют ir. Они используют хайлевел llvm-api через биндинги.
Повторю ещё раз. Те части, которые в rustc написаны на rust могут генерировать ТОЛЬКО mir. Из этого факта никак не следует, что llvm должен начать понимать mir.
Нет. Раст не выполняется нативно — нативном выполняется нативный код. Для того и нужен компилятор.
Там уже нечего комментировать. Ваша аргументация зашла в тупик.
Нет. Контекст был «на rust». rustc не генерирует ir — его генерирует llvm.
Я уже это говорил. mir — это единственное, что генерирует rustc сам. Вы утверждали, что rustc является компилятором(транслятором) во что-то там. Вы не уточняли во что именно он транслируется(понятно что в ir).
И вот, когда вы знаете, что rustc(сам) генерирует только mir. Таким образом отсюда:
Может следовать только «таргет == mir». Почему mir не может являться и таргетом и промежуточным представлениям понятно.
Таким образом я доказал, что ваше утверждение некорректно и не имеет смысла.
Конкретика. Где «хамить» и в чём «хамить» заключается.
Выводы я сделал выше. Я опроверг ваши наивные рассуждения про lisp-машины. Я опроверг ваши рассуждения про «можно сделать какой угодно исполнитель». Нельзя. Этим никто не будет заниматься. Это практический вывод.
Из этого ничего не следует. Разговор был о хардварных исполнителях. Я вам дал возможность подменить тему на софтварные исполнители. В очередной раз подменить тему я вам не дам.
Какое это имеет отношение к теме? Мы не обсуждали исполняемый код, а обсуждали исполнитель.
Даже больше скажу. Я утверждал(и именно об этом я говорил), что исполнитель под «неэффективно» нельзя сделать эффективно. Это одно из следствий. И даже непросто «сделать эффективно» просто «сделать» нельзя.
Зачем это написано — я не знаю.
Пруфы. К тому же, что вообще из этого следует? Я опроверг ваши рассуждения. Абсолютно неважно то, чем является mir. Таргетом в rustc может является только он, ведь только его генерирует rustc сам.
Это набор слов. Узнайте значение понятия «таргет». Внутреннее представление, либо промежуточное представление — это по определению то, что находится до таргета. Если бы оно было таргетом — оно бы не называлось промежуточным/внутренним.
И? Я вас где-то спрашивал про «что такое промежуточное представление»? Я вас где-то спрашивал про «что такое абстракции»? Нет и нет. Зачем вы мне это пишите?
Вы пытались сказать, что в rustc rust-код генерирует ir. Это неправда. Вам нужно на это отвечать.