The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Новая криптографическая библиотека EverCrypt с математически..., opennews (??), 06-Апр-19, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


14. "Новая криптографическая библиотека EverCrypt с математически..."  –2 +/
Сообщение от пох (?), 06-Апр-19, 14:25 
> как это понять?

авторы как хотят, так и лицензируют. Почему-то для кода на F им захотелось более ограничительную лицензию, а за скомпилированный они меньше переживают, и большее разрешают с ним делать (что может быть нужно для его интеграции в ту же мазилу).

> а исходный код скомпилированного варианта тогда под какой лицензией

исходный код скомпилированного _тобой_ варианта - apache, только ты ниасилишь доказательство его правильности после компиляции, поэтому он феерически бесполезен, одна openssl уже есть.

Ответить | Правка | Наверх | Cообщить модератору

21. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним (21), 06-Апр-19, 15:42 
> за скомпилированный они меньше переживают

Читаем внимательно

> На основании эталонного кода на языке F* затем генерируется код на ассемблере, Си, OCaml, JavaScript и Web Assembly.

О скопмилированном коде тут речь не идет. Поэтому не путайте. Скомпилированный исходный код под той же лицензией, что и сам исходный код.

Ответить | Правка | Наверх | Cообщить модератору

26. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от пох (?), 06-Апр-19, 17:52 
> О скопмилированном коде тут речь не идет.

о, очередной "программист" самоучка? Компилятор с F на C - вполне себе компилятор, и код этот - компилированный. Что тебе бы рассказали на первом курсе института, если бы ты его посещал.

И именно о нем речь и идет.
(Забавно, кстати, что разглядывавшие этот код люди нашли его более читаемым чем код аналогичного свойства, написанный человеками.)

так вот с кодом, который скомпилировали разработчики - можешь делать что угодно. С кодом, который ты накомпилируешь сам из F* - только в рамках apache license.

что в целом и правильно, бойтесь программистов-самоучек-без-мотора, дорвавшихся до криптографии.

Ответить | Правка | Наверх | Cообщить модератору

30. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним (27), 06-Апр-19, 18:53 
>С кодом, который ты накомпилируешь сам из F* - только в рамках apache license.

https://ru.wikipedia.org/wiki/Лицензия_Apache
"Согласно Free Software Foundation, GPLv3 совместима с Apache License v2.0. Как следствие, разработчики всегда имеют возможность свои программы под Apache License v2.0 перевести под GPL v3.0, чтобы быть уверенными в том, что производные их разработок (форки) останутся свободными."
Так что можешь хоть под GPL прелицензировать, то, что сам странслировал с F*.

Ответить | Правка | Наверх | Cообщить модератору

51. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от пох (?), 06-Апр-19, 23:17 
> Так что можешь хоть под GPL прелицензировать, то, что сам странслировал с
> F*.

не можешь. Ибо ты - не разработчик и не владелец авторского права ни на исходник, ни на странслированное, сюрпрайз.

А разработчики могут перевести хоть под коммерческую лицензию, как уже не раз случалось. Или, вот, вовсе под MIT. Поскольку, внезапно, их может совершенно не беспокоить "останутся ли свободными" форки их проекта.

Ответить | Правка | Наверх | Cообщить модератору

31. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 06-Апр-19, 18:58 
речь идет именно о сгенерированном Си коде, никакой компиляции

https://github.com/project-everest/hacl-star/tree/master/sna...

и собственно о лицензиях

Licenses

All F* source code is released under Apache 2.0.
All generated C, OCaml, Javascript and Web Assembly code is released under MIT.


внимание на "All generated"

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

40. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от Аноним (40), 06-Апр-19, 20:33 
> речь идет именно о сгенерированном Си коде, никакой компиляции

Автоматическая генерация кода на одном языке из исходников на другом с потерей человекочитаемости называется компиляцией. Выходной язык не обязан быть машинным кодом.

Ответить | Правка | Наверх | Cообщить модератору

45. "Новая криптографическая библиотека EverCrypt с математически..."  –2 +/
Сообщение от Sw00p aka Jerom (?), 06-Апр-19, 21:12 
>с потерей человекочитаемости называется компиляцией

)))) пройдите по ссылке указанной выше, и вовсе не компиляция, а трансляция (кодогенерация)

пс: цитата из вики, для особо одаренных

"Компили́ровать — проводить трансляцию машинной программы с предметно-ориентированного языка на машинно-ориентированный язык"

и с коих пор Си - машинно-ориентированный?

Ответить | Правка | Наверх | Cообщить модератору

49. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от пох (?), 06-Апр-19, 22:50 
> пс: цитата из вики, для особо одаренных

вашу викивракию пишут такие же "эксперты" как и вы - не посещавшие даже лекции для первокурсников про теорию компиляторов. Так, что-то слышавшие краем уха.

> "Компили́ровать — проводить трансляцию машинной программы с предметно-ориентированного
> языка на машинно-ориентированный язык"

во бред-то
> и с коих пор Си - машинно-ориентированный?

с каких пор он "предметно-ориентированный" - тоже забавный вопрос.
Это, видимо, из какой-то книжки про Алгол (или про кобол) списано, не вдаваясь в подробности в каком году и какими специалистами она написана.

Ответить | Правка | Наверх | Cообщить модератору

57. "Новая криптографическая библиотека EverCrypt с математически..."  +2 +/
Сообщение от Sw00p aka Jerom (?), 07-Апр-19, 00:35 
>не посещавшие даже лекции для первокурсников про теорию компиляторов.

ок, понятно, а теперь ответьте на один вопрос - кто автор "теории компиляторов"? ответите и дальше продолжим дискуссию.

>не вдаваясь в подробности в каком году и какими специалистами она написана.

ну вот отлично, жду ответа на свой вопрос.

пс: как называется процесс "текст на русском" -> "текст на английском" ?
вот коту моему все равно с какого на какой язык транслировали, ему нужно в итоге транслировать в "кыскыскыс", "мяумяу", "ахтыскотина", "брысьотсюда". Моему желудку все равно каков рецепт и какую душу вложил кулинар, ему важней объем белков, жиров и углеводов.

Ответить | Правка | Наверх | Cообщить модератору

58. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 07-Апр-19, 00:37 
про первокурсников, а вы собственно из серии программистов которым "не нужна математика"?
Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

68. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от t_ (?), 07-Апр-19, 12:53 
Самое забавное, что он прав и в вики это тоже верно написано.

Перечитайте что ли вводную главу книги драконов.

Кричать про экспертов и, при этом, не отличать компилятор от транслятора - гиблое дело.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

75. "Новая криптографическая библиотека EverCrypt с математически..."  +1 +/
Сообщение от Аноним84701 (ok), 07-Апр-19, 16:46 
Девочки, не ссорьтесь!

Cуществует "и то и это".
Остроконечники^W различающие "перевод" (трансляцию) и тупоконечники^W считающие компиляцию частным случаем трансляции. Тоже  "0 ∈ ℕ vs 0  ∉ ℕ", только в профиль.
Классический пример: "переводчик формул" (FORmula TRANslation, FORTRAN)

> Перечитайте что ли вводную главу книги драконов.

Цитирую, с картинками:

> 1.1. Language Processors
> Simply stated, a compiler is a program that can read a program in one language -- the source language -- and translate it into an equivalent program in another language -- the target language; see Fig.1.1
> An important role of the compiler is to report any errors in the source program that it detects during the translation process.
>Figure 1.1: A compiler


source program
        |
        v
+-------------+
|   Compiler  |
+-------------+
       |
       v
target program

В той же англоязычной википедии стоит:
> A compiler is a computer program that translates computer code written in one programming language (the source language) into another programming language (the target language).

Более того, с этим же "согласны"  берклеевцы:
http://inst.eecs.berkeley.edu/~cs164/sp19/lectures/lecture1.pdf
> Implementing Programming Languages
> • Strategy 2: Compiler: program that translates program into machine

[...]
> – Variant of 2: Compiler that translates program into another programming language (such as C), or into an intermediate language (such as Java class format) for which there is a translator or compiler.

Т.е. компилятор тут - частный случай/разновидность транслятора.

> Кричать про экспертов и, при этом, не отличать компилятор от транслятора - гиблое дело.

Судить по этому критерию о качестве знаний - не менее гиблое.

Ответить | Правка | Наверх | Cообщить модератору

81. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 07-Апр-19, 18:58 
>Т.е. компилятор тут - частный случай/разновидность транслятора.

Да, но именно результат "компиляции" (это типа последняя фаза трансляций) может спокойно исполняться на конечной машине, даже "Ассемблер" транслируя ассемблерный код в "нули и единицы", которые могут спокойно исполниться машиной, совершает процесс "компиляции" (то есть привести к виду "исполняемого" на конкретной машине).

Ответить | Правка | Наверх | Cообщить модератору

83. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним84701 (ok), 07-Апр-19, 19:41 
>>Т.е. компилятор тут - частный случай/разновидность транслятора.
> Да, но именно результат "компиляции" (это типа последняя фаза трансляций) может спокойно
> исполняться на конечной машине,

Может, а может и нет. Я просто подсказываю, что зависит от используемой (вполне общепринятой) терминологии с использованием более общего понятие "compiler" (т.е. включая переводчик).
Я вообще не собираюсь спорить о том, чья классификация (не)правильная. Просто (по факту) есть и та и другая, используется специалистами и по моему глупо игнорировать или делать вид, что  "правильно только наше понимание и наша терминология!".

> даже "Ассемблер" транслируя ассемблерный код в "нули  и единицы", которые могут спокойно исполниться машиной, совершает процесс "компиляции"

Э-э-э не-не, ассемблер как раз обычно вне таких классификаций и стоит особняком.

Если брать ту же Книгу Драконов, то assembly там одна из возможных конечных целей компилятора.
Хотя сам процесс превращения современного assembly-кода c его тучей макросов, структур и довольно сложными вычислениями "времени ассемблеризации"  и прочим, вполне тянет на "полноценную" компиляцию.
В общем, "все сложно".

Правда, я не припоминаю ни одной "накладки" или путанницы из-за этого на практике, потому что если различие важно из-за нюансов, то это упомянут и подчеркнут отдельно, а если пишуший не в курсе, то это обычно не единственная проблема в статье-артикле :)

Ответить | Правка | Наверх | Cообщить модератору

86. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 07-Апр-19, 20:25 
>Э-э-э не-не, ассемблер как раз обычно вне таких классификаций и стоит особняком.

нет не стоит, и он от ЯП других ничем не отличается, ибо он из мнемонического кода транслирует в коды операций процессора. И я именно эту стадию считаю как понятие "компиляции", в других случаях это все трансляция (перевод).

тип такого:

англ ->(тут перевод в) рус ->(тут перевод в) нем ->(тут компиляция) кошачий. :)

>Если брать ту же Книгу Драконов, то assembly там одна из возможных конечных целей компилятора.

что есть конечная цель? представить код "понятный" процессору (машине).

>Хотя сам процесс превращения современного assembly-кода c его тучей макросов, структур и довольно сложными вычислениями "времени ассемблеризации"  и прочим, вполне тянет на "полноценную" компиляцию.

ну да так и есть, и в результате получаем исполняемый код.

>Правда, я не припоминаю ни одной "накладки" или путанницы из-за этого на практике

так проблема в строгом определении любого понятия, ибо если его нет, то все ведет к таким дискуссиям (холиварам). Можем еще и похоливарить на тему JIT компиляции.

Ответить | Правка | Наверх | Cообщить модератору

87. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним84701 (ok), 07-Апр-19, 20:51 
> нет не стоит, и он от ЯП других ничем не отличается,

То что не отличается, я даже не спорил, а вот то что все же стоИт, пусть в основном и по историческим причинам "так принято" - с этим как раз сталкиваешься достаточно часто (см. man gcc опция -S или -c)
>  И я  именно эту стадию считаю как понятие "компиляции", в других случаях это  все трансляция (перевод).

*пожимая плечами* а авторы библиотеки похоже придерживаются другой классификации и наверное стоит принимать во внимание в первую очередь ее.

>>Если брать ту же Книгу Драконов, то assembly там одна из возможных конечных целей компилятора.
> что есть конечная цель? представить код "понятный" процессору (машине).

Это очередная неточность перевода:
Конечная цель - в смысле результата работы самого компилятора: в оригинале "compiler target".

Ну и не припоминается ни одного современного компилятора, генерирующего сразу машинный код.
В качестве еще одного примера приходит на ум тот же (g)as, как "классический" бэкэнд для gcc.
Кстати, там (как и в clang, других компиляторов чтобы проверить, у меня сейчас нет), как раз различают этот нюанс:


man gcc
-c  Compile or assemble the source files, but do not link.  The linking
           stage simply is not done.  The ultimate output is in the form of an
           object file for each source file.
[...]
           Unrecognized input files, not requiring compilation or assembly,
           are ignored.

       -S  Stop after the stage of compilation proper; do not assemble.

man clang
-c     Run all of the above, plus the assembler, generating a target
              ".o" object file.


> так проблема в строгом определении любого понятия, ибо если его нет, то
> все ведет к таким дискуссиям (холиварам). Можем еще и похоливарить на  тему JIT компиляции.

Вообще-то я считаю, что намного важнее ввести отдельный термин смузилятор для  обзначения трансляции кода старых ЯП в относительно  новые с помощью нейронных сетей, работающих на смузи :)

Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

88. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 07-Апр-19, 21:28 
>Конечная цель - в смысле результата работы самого компилятора: в оригинале "compiler target".

Так результат работы того же gcc с опцией -c (Compile or assemble) на выходе даёт "The ultimate output is in the form of an object file for each source file.", обратим внимание на "object file", что это? это разве промежуточный код?

открываем википедию и читаем

"Объектные файлы представляют собой блоки машинного кода и данных с неопределенными адресами ссылок на данные и процедуры в других объектных модулях, а также список своих процедур и данных."

А компоновщик уже тупо свяжет их, и создаст полноценный исполняемый файл.

Так, что же в итоге такое процесс компиляции, как не трансляция в машинные коды операций.


>Ну и не припоминается ни одного современного компилятора, генерирующего сразу машинный код.

Go-lang - не? "сразу машинный код" может сгенерить только очень близкий к машинному ЯП, то есть "Ассемблер как ЯП"

>как и в clang, других компиляторов чтобы проверить, у меня сейчас нет

если брать llvm, то clang транслирует в биткод llvm (промежуточный), и собственно ассемблер llvm готовит машинный.

Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

94. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним (94), 08-Апр-19, 11:57 
>>Т.е. компилятор тут - частный случай/разновидность транслятора.
> Да, но именно результат "компиляции" (это типа последняя фаза трансляций) может спокойно
> исполняться на конечной машине, даже "Ассемблер" транслируя ассемблерный код в "нули
> и единицы", которые могут спокойно исполниться машиной, совершает процесс "компиляции"
> (то есть привести к виду "исполняемого" на конкретной машине).

"Ассемблер" совершает процесс "ассемблирования". Это когда каждая мнемоника транслируется в машинную команду 1 в 1. Есть ещё макроассемблеры, позволяющие генерировать группы команд по шаблону (макросу). А есть т.н. "assembly compiler". Например, https://en.wikipedia.org/wiki/High_Level_Assembly -- первые версии компилировали исходный код в исходники для других ассемблеров. Однако, ключевым отличием "компилятора ассемблера" является способность производить не всеми очевидные преобразования (в частности, оптимизации), когда один и тот же фрагмент исходного текста порождает различный машинный код.

И, кстати, выхлоп после мало какого ассемблера может исполняться без линковки непосредственно.


Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

105. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от Sw00p aka Jerom (?), 08-Апр-19, 16:52 
>первые версии компилировали исходный код в исходники для других ассемблеров.

это не компиляция!!! - а перевод (трансляция, кодогенерация в другой язык, называйте как хотите)

компайлед или там ассемблед это уже готовый машинный код, который исполняется. Исходный код на питоне странсилованный в исходный код на Си - исполнится?

Ответить | Правка | Наверх | Cообщить модератору

116. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним (94), 09-Апр-19, 07:59 
>>первые версии компилировали исходный код в исходники для других ассемблеров.
> это не компиляция!!! - а перевод (трансляция, кодогенерация в другой язык, называйте
> как хотите)

"Это" была цитата (в переводе) René Tournois (Betov), автора SpAsm и RosAsm (см. https://web.archive.org/web/20040602212238/http://betov.free...

Возможно, его мнение несколько предвзято, поскольку заявлено в священной войне с Randall Hyde (автором HLA), но это мнение -- практика.

> компайлед или там ассемблед это уже готовый машинный код, который исполняется. Исходный
> код на питоне странсилованный в исходный код на Си - исполнится?

Не вижу связи с классификацией ассемблеров.

Ответить | Правка | К родителю #105 | Наверх | Cообщить модератору

99. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от t_ (?), 08-Апр-19, 13:59 
Ты молодец. Открыл нужную книгу, выделил слово translate, но вывод сделал неверный.

Компилятор не является частным случаем или разновидностью транслятора.
Компиляция вообще с трансляцией не связана, это разные процессы.

Транслятор является подпрограммой компилятора. Если выкинуть транслятор из компилятора, то команды на выходе будут в том же виде, что на и на входе (если не использовалась оптимизация). То есть никакого перевода из одного языка в другой, хоть высокого уровня, хоть машино-зависимого, без трансляции не произойдёт. Ещё там есть различные анализаторы, которые тоже к компиляции никакого отношения не имеют.

Не надо путать компилятор-программу и компиляцию-процесс.

Трансляция занимается переводом.
Компиляция занимается сборкой.

Чтобы это понять, достаточно даже открыть не книгу про компиляторы, а просто словарь английского языка.

>> Кричать про экспертов и, при этом, не отличать компилятор от транслятора - гиблое дело.
> Судить по этому критерию о качестве знаний - не менее гиблое.

Согласен.
Но у человека много гонора, и прежде чем посылать других на курсы, неплохо было бы ему самому на них сходить.
Почитай его комменты, у него есть опыт и из-за этого сильно развито ЧСВ, а база-то непрочная для дискуссий.

Ответить | Правка | К родителю #75 | Наверх | Cообщить модератору

109. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним84701 (ok), 08-Апр-19, 21:56 
> Ты молодец. Открыл нужную книгу, выделил слово translate, но вывод сделал неверный.
> Компилятор не является частным случаем или разновидностью транслятора.
> Компиляция вообще с трансляцией не связана, это разные процессы.
> Транслятор является подпрограммой компилятора.
> Если выкинуть транслятор из компилятора,

Еще раз - "translator" в _этом_ варианте англоязычной терминологии  вообще как-то специально не выделяется (кроме процесса "translation").
А еще есть такое понимание:
https://www.microcontrollertips.com/compilers-translators-in.../
> Translators
> The most general term for a software code converting tool is “translator.”
>  A translator, in software programming terms, is a generic term that could refer to a compiler, assembler, or interpreter;

Короче, мне далее срат^W обсуждать тонкости различия терминологии в  переводе не интересно -- изначально речь шла о формулировках в #14-#21
>> На основании эталонного кода на языке F* затем генерируется код на ассемблере, Си, OCaml, JavaScript и Web Assembly.
> О скопмилированном коде тут речь не идет. Поэтому не путайте. Скомпилированный исходный код под той же лицензией, что и сам исходный код.

Т.е. именно в этом контексте различать "translator" и утверждать "translation != compilation" (точнее, заявлять что генерация кода != компиляция поэтому не считается) … не, конечно можно, но смысл, если из контекста документации и описания понятно, что авторы придерживаются другой терминологии и вряд ли комментарии на опеннете ее изменят?

Ответить | Правка | Наверх | Cообщить модератору

114. "Новая криптографическая библиотека EverCrypt с математически..."  +2 +/
Сообщение от t_ (?), 09-Апр-19, 01:21 
> A translator, in software programming terms, is a generic term that could refer to a compiler, assembler, or interpreter;

Всё правильно написано, поскольку ни компилятор, ни интерпретатор, ни сборщик не имеют смысла без трансляции
Потому что именно трансляция отвечает за перевод данных из исходной формы в результирующую.

Здесь нет никакого противоречия.


Этот термин пришёл из обработки документов. К ней он и относится, и означает упорядочение информации собранной из разных источников.

Представь, что у тебя есть набор лабораторных работ. Из которых тебе надо сделать курсовую. Наверное слышал словосочетание "скомпилированная работа"?

1) Ты берёшь эти лабораторки и копируешь в один большой текст. Компиляция была? Была.
Аналог для программирования: все исходники в дереве кода прогоняются через компилятор, без трансляции - на выходе получается то же самое. И значит работа бессмысленна. Поэтому трансляция неотделимая часть компиляции. Но это разные вещи.

2) Ты берёшь эти лабораторки, копируешь их в большой текст, потом берёшь и редактируешь текст, добавляешь новый, переставляешь абзацы местами, задействуешь синонимайзеры. Компиляция была? Разумеется была. Она всегда есть! В данном случае с оптимизацией.

3) Ты берёшь эти лабораторки, но тебе надо написать работу на английском. Ты их переводишь и сохраняешь в один текст.
Аналог: компиляция выполнена с трансляцией (переводом). На выходе результат на другом языке. И только в случае трансляции получается ДРУГОЙ язык, например Vala => C.

4) У тебя работа почти готова, но ты решил добавить немного информации из других источников, помимо лабораторок и добавил чертежи (например, блок-схему).
Аналог: компиляция выполнена с компоновкой внешних файлов.

Таким образом, можно увидеть, что компиляция как глобальный процесс занимается менеджерскими задачами, по передаче кода программы различным парсерам, трансляторам, сборщикам, оптимизаторам и т.д. для получения готового результата.
Но так как в кодогенерации компиляция и интерпретация не имеют смысла без трансляции, то компиляторы и интерпретаторы общепринято называются трансляторами.

Называть компиляцию трансляцией это всё равно что называть жизнь человеческого тела дыханием. Типа, процесс трансляции кислорода в углекислый газ является жизнью человеческого тела.

Конечно, от более глубокого понимания нюансов программировать лучше не станешь, но стоит иногда задумываться над тем, чем мы занимаемся.

Вот на это отличие обратил внимание Sw00p aka Jerom.
У него пока тоже нет полного понимания, но можно было бы объяснить ему это по-человечески, не самоутверждаясь.

Ответить | Правка | Наверх | Cообщить модератору

117. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 09-Апр-19, 18:41 
>трансляция отвечает за перевод данных из исходной формы в результирующую.

если "результирующую" понимать как конечный этап (машинные коды операций), то да это и есть по моему мнению процесс компиляции, объединяющий в себе понятия "итоговой трансляции", "сборки" (assembly - в прямом смысле) и собственно "связи" (linkage).

Хочу отметить, что я делаю именно акцент на "конечный этап трансляции" - это и есть компиляция. Вот такое строгое мое мнение понятия компиляции.

>Представь, что у тебя есть набор лабораторных работ. Из которых тебе надо сделать курсовую. Наверное слышал словосочетание "скомпилированная работа"?

###
Сырбор всей дисскуссии начался с того, что "трансляция" (перевод) с одного исходного текста ЯП на другой исходный текст был назван как процесс компиляции. (Что по моему мнению - ложно. И попытаюсь это доказать в итоге.)
###

>Ты берёшь эти лабораторки и копируешь в один большой текст. Компиляция была? Была.

Нет, не была. Была "сборка" в выше указанном моем определении процесса компиляции.

>Компиляция была? Разумеется была. Она всегда есть! В данном случае с оптимизацией.

Нет, не была, таже самая "сборка". Оптимизацию объясню ниже.

>Аналог: компиляция выполнена с трансляцией (переводом).

Из моего определения процесса компиляции - "итоговая трансляция" (конечный этап).


>На выходе результат на другом языке. И только в случае трансляции получается ДРУГОЙ язык, например Vala => C.

И как я понял, в итоге по вашему мнению "процесс компиляции" есть процесс трансляции из языка A в язык B.

Отсюда, по вашему мнению, процесс трансляции (перевода) из Python в C - есть процесс компиляции, так ли это ? Если да, то приведу такой пример.

Допустим, есть множество языков вида L1, L2, L3 ... LN, где LN есть "результирующий язык" (машинные коды операций), а пронумерованные это прочие высокоуровневые ЯП. Введем оператор трансляции "->" (стрелочка).

Из вашего мнения следует L1 -> L2 - есть процесс компиляции, тогда L1 -> L1` (штрих) также есть процесс компиляции. L1` (штрих) - тут в роли процесса "обфускации" или же "рефакторинга", та же "оптимизация". И получается, что это так же трансляция если строго трансляцию не принимать как только L1 -> L2.


>Таким образом, можно увидеть, что компиляция как глобальный процесс занимается менеджерскими задачами, по передаче кода программы различным парсерам, трансляторам, сборщикам, оптимизаторам и т.д. для получения готового результата.

"для получения готового результата" - то есть исполняемого? Если да, то Python -> C, где тут "готовый результат"? Вы противоречите своему определению процесса компиляции.


>Но так как в кодогенерации компиляция и интерпретация не имеют смысла без трансляции, то компиляторы и интерпретаторы общепринято называются трансляторами.

Тут как-то сумбурно, кодогенерации это фактическая трансляция.


>Вот на это отличие обратил внимание Sw00p aka Jerom.
>У него пока тоже нет полного понимания, но можно было бы объяснить ему это по-человечески, не самоутверждаясь.

Нет полного понимания из-за того, что нет строгого определения "процессу компиляции". И поэтому тут имеет место быть разным мнениям. Но нужно ведь прийти к единому строгому определению, а единственный верный путь - путь без противоречий.

Если бы каждый шаг L1 -> L2 -> L3 ... -> LN и весь процесс трансляций в целом называть компиляцией, то зачем мы еще порождаем всякие понятия L1 -> L1` (штрих) как "обфускация", "рефакторинг", "оптимизация"?

Почему мы принимаем Java как "компилируемый язык"?

Пример:

Python -> Java -> Java-bytecode (конечный этап трансляции для JVM)

Этот пример имеет место быть, так как Java-bytecode тут конечный этап трансляции для JVM, и по моему мнению (когда конечный этап - это машинные коды операций), компиляция тут заключается только лишь в процессе трансляции Java -> Java-bytecode, но не Python -> Java. И эту компиляцию, для строгого отличия от "нативной" (Asm -> CPU Opcodes), я называю - "виртуальной компиляцией".

Тоже самое: C -> Asm -> CPU Opcodes, Asm -> CPU Opcodes - последняя стадия трансляции - компиляция, C -> Asm - просто трансляция (обычно говорят кодогенерация)

пс: всем спасибо за участие в дискуссии.

Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

118. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от t_ (?), 10-Апр-19, 02:38 
Изначально верный ответ дал Аноним84701 :D
> Девочки, не ссорьтесь!
> Cуществует "и то и это".

===============================

> если "результирующую" понимать как конечный этап (машинные коды операций), то да это и есть по моему мнению процесс компиляции

В программировании конечный этап компиляции так же не обязательно является машинным кодом, он так же может быть исходным кодом на ЯВУ, или любом другом (см. ниже).

> Хочу отметить, что я делаю именно акцент на "конечный этап трансляции" - это и есть компиляция.

Ну, это тоже не обязательно так, потому что компиляторы бывают разные и могут включать в процесс компиляции и трансляцию, и сборку, если нужно. В компиляторах процесс часто начинается с компиляции, и ей же заканчивается, при этом на выходе получается отранслированный, собранный, оптимизированный и даже исполняемый код. А линковка, компоновка и окончательная сборка может быть включена в процессе компилятора, а может и не включаться. Для их выполнения могут использоваться вызовы внешних утилит, как отдельно от компилятора (в каком нибудь скрипте сборки), так и самим компилятором.

> Сырбор всей дисскуссии начался с того, что "трансляция" (перевод) с одного исходного текста ЯП на другой исходный текст был назван как процесс компиляции. (Что по моему мнению - ложно. И попытаюсь это доказать в итоге.)

Да не ложно это.
В компиляторе есть две вещи - обработка данных (процессинг) и организация данных (компиляция - организация данных собранных из разных источников). Организационный процесс передаёт управление процессам связанным с обработкой данных - транслятору, оптимизатору, сборщику и пр. Берёт код в одной форме, передаёт другому процессу, получает код в новой форме, передаёт следующему.
Компиляция как глобальный процесс без трансляции не имеет смысла. (Но она возможна на уровне какого-нибудь интеллектуального оптимизатора. К примеру, разворачивание циклов без изменения языка исходного кода.). Поэтому часто пишут, что компилятор выполнил перевод из одного языка в другой. Я ниже в сообщениях приводил пример, как это выглядит в отношении пакета vala:

vala-0.40.11,1                 Programming language and compiler that converts Vala code into C code

Никаких проблем с переводом из языка в язык при компиляции нет. Просто вы с товарищем пох смотрите на проблему с разных уровней. И хотя есть разница между процессами, правы вы оба. Действительно, процессом перевода занимается трансляция и действительно, она выполняется в процессе компиляции.

> Если бы каждый шаг L1 -> L2 -> L3 ... -> LN и весь процесс трансляций в целом называть компиляцией, то зачем мы еще порождаем всякие понятия L1 -> L1` (штрих) как "обфускация", "рефакторинг", "оптимизация"?

Потому что приходится различать дополнительные процессы внутри компиляции, которые обрабатывают разные промежуточные результаты по разным алгоритмам.

> Почему мы принимаем Java как "компилируемый язык"?

Потому что он компилируется в байт-код для виртуальной машины.

Но понятие "компилируемый язык" лично я не люблю. Потому что это зависит от реализации.
Например, для бейсика выпускались как компиляторы, так и интерпретаторы.

Или вот строчка из вики про Python: "В отличие от компилируемых языков программирования, в Python...".
То есть Python, фактически, объявляется некомпилируемым языком. И при этом "Файлы .pyc содержат скомпилированный байт-код исходных файлов Python". Но как же так? Ведь Python объявили интерпретируемым языком, а оказывается это не мешает его скомпилировать. Причём делает это лично интерпретатор Python, потому что в нём есть модуль компиляции.

Мне больше нравится такое утверждение:
"a language is not "interpreted" or "compiled" as such. A specific implementation can be an interpreter or a compiler (or a hybrid or a JIT compiler or a vm etc)".

Написать интерпретатор java помешает лицензия и огромный объём работы, но возможность этого никто не отменял. :)
Будет своя тормозная реализация интерпретатора джавы без виртуальной машины.
Можешь даже сам попробовать реализовать интерпретатор хотя бы для небольшого подмножества джавы (хотя бы операторы c++) и всё будет работать. Компилируемый, интерпретируемый - это просто ярлыки, применимые для конкретных реализаций.

> компиляция тут заключается только лишь в процессе трансляции Java -> Java-bytecode, но не Python -> Java

Именно тут ошибка.

Твоё недопонимание в том, что ты воспринимаешь процесс компиляции как отдельный процесс обработки данных. А он занимается организацией и передачей/приёмом обрабатываемых данных далее по цепочке. А проблема в том, что в основном компиляция использовалась для перевода исходного кода в машинный. Вот и привыкли так считать.

К dragonbook, и раз тебе нравится вики, можно добавить ссылку:
https://en.wikipedia.org/wiki/Source-to-source_compiler

> пс: всем спасибо за участие в дискуссии

Взаимно! :)

-------------------------------------------------------

Резюме:
1) компиляция != трансляция - процессы разные, трансляция выполняется внутри компиляции
2) компилятор == транслятор - компилятор выполняет трансляцию в процессе компиляции
3) "конечный этап" не обязательно равен "машинные коды операций". это частный случай. можно скомпилировать исходный код одного языка в исходный код другого

Пожелание:
Смотрим рисунок 1.4 в книге драконов, думаем, почему вся схема называется схемой гибридного компилятора, и почему в ней есть прямоугольник с надписью транслятор.

На этом я завершаю свой флуд.

Ответить | Правка | К родителю #117 | Наверх | Cообщить модератору

119. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 10-Апр-19, 15:03 
Если приводить цитаты из вики, то повторюсь:

https://en.wikipedia.org/wiki/Source-to-source_compiler

Читаем раздел history:

"""
One of the earliest programs of this kind was Digital Research's XLT86 in 1981, a program written by Gary Kildall, which translated .ASM source code for the Intel 8080 processor into .A86 source code for the Intel 8086.
"""

Суть такого компилятора ограничивалась уже самым "конечным яп".

Но читаем дальше раздел Programming language implementations:

И видим, что скрестили ежа с ужем.

Но давайте остоновимся на определении:

"""
A source-to-source compiler is a type of compiler that takes the source code of a program written in a programming language as its input and produces the equivalent source code in the same or a different programming language.
"""

То есть "Транспайлер — тип компилятора", а что такое компилятор из той же вики?

https://ru.wikipedia.org/wiki/%D0%9A%D0%...

"""
Компиля́ция — сборка программы, включающая трансляцию всех модулей программы, написанных на одном или нескольких исходных языках программирования высокого уровня и/или языке ассемблера, в эквивалентные программные модули на низкоуровневом языке, близком машинному коду (абсолютный код, объектный модуль, иногда на язык ассемблера)[2][3][4] или непосредственно на машинном языке или ином двоичнокодовом низкоуровневом командном языке и последующую сборку исполняемой машинной программы.
"""

А сам процесс описан строго:

"""
Компили́ровать — проводить трансляцию машинной программы с предметно-ориентированного языка на машинно-ориентированный язык
"""

А теперь повторно задам вопрос: Трансляция из Python -> C, C - является "машинно-ориентированным языком"? Если нет, то как можно этот процесс трансляции называть компиляцией?

пс: Из вашего мнения следует, помимо "обфускации", "рефакторинга", "оптимизации", что и обычное "редактирование" исходного кода есть процесс компиляции. Так ли это?


пс2: Выше Пох подставил под сомнение статью в википедии об компиляторе, но в тоже самое время приводит из неё же статью про транспайлер, в которой ссылка на понятие компилятора. И вы собственно так же поступаете, не противоречивы ли ваши действия?

Ответить | Правка | К родителю #118 | Наверх | Cообщить модератору

120. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от t_ (?), 10-Апр-19, 23:40 
> А теперь повторно задам вопрос: Трансляция из Python -> C, C - является "машинно-ориентированным языком"? Если нет, то как можно этот процесс трансляции называть компиляцией?

Я тоже повторно объясню: компиляция не требует обязательного результата в виде машинно-ориентированного языка, потому что она не относится к обработке данных. Преобразованием в другой язык занимается трансляция в процессе работы компилятора, внутри процесса компиляции.

"A source-to-source COMPILER is a type of COMPILER that takes the source code of a program written in a programming language as its input and PRODUCES the EQUIVALENT SOURCE CODE in the same or a different programming language."

Что в слове compiler непонятно? При такой компиляции, без трансляции в машинно-ориентированный язык, никакого машинно-ориентированного языка на выходе нет.

> пс: Из вашего мнения следует, помимо "обфускации", "рефакторинга", "оптимизации", что и обычное "редактирование" исходного кода есть процесс компиляции. Так ли это?

Очень хороший и интересный вопрос.
Вообще-то любой процесс трансляции, обфускации и прочих это тоже редактирование кода. Ведь он в итоге будет изменён и представлен в виде исходного кода на другом языке, или байт-коде или ином представлении. Но обычным редактированием это не назовёшь.

Но компиляция не об этом, она об организации данных из разных источников. Что подразумевается под разными источниками? Это, во-первых, источники данных на входе процесса компиляции (например, файлы в дереве кода и за его пределами), а во-вторых - обработанные данные на выходах промежуточных процессов, которые занимаются преобразованием данных внутри процесса компиляции (Здесь и выше я специально выделяю процесс компиляции, потому что ещё есть промежуточные процессы внутри трансляции и прочих процессов. Они отношения к компиляции не имеют, как и их результативные данные.)

Поэтому ответ: нет. Компилятор должен выполнять преобразование кода из языка в другое представление, а этим занимается трансляция. Остальные процессы не являются обязательными, и поэтому их не используют в качестве синонимов компиляции.


> пс2: Выше Пох подставил под сомнение статью в википедии об компиляторе, но в тоже самое время приводит из неё же статью про транспайлер, в которой ссылка на понятие компилятора. И вы собственно так же поступаете, не противоречивы ли ваши действия?

Это не противоречие, а дополнение.
Включи логику уже. :)

Истинно ли высказывание в вики, или ложно?

1) Из определения уже явно видно, что оно состоит из двух утверждающих частей, и что преобразование в язык, близкий к машинному коду тоже выполняется трансляцией: "(включающая ТРАНСЛЯЦИЮ всех модулей программы, написанных на одном или нескольких исходных языках программирования высокого уровня и/или языке ассемблера, В эквивалентные программные МОДУЛИ НА низкоуровневом ЯЗЫКЕ, БЛИЗКОМ МАШИННОМУ КОДУ)" - это одна часть. Никакой речи о компиляции, которая что-то переводит в другое представление (машинно-зависимый язык и пр.), не идёт. И правильно, компиляция не занимается переводом в машинно-зависимый код, что ты утверждаешь, ссылаясь на это определение. А где же речь о компиляции? А она в оставшейся части:

2) (Компиляция - СБОРКА программы), (тут первая часть про трансляцию). Вот же компиляция, она просто передаёт исходные данные транслятору и СОБИРАЕТ результаты трансляции в конкретную форму, необходимую для дальнейшей обработки и передачи другим процессам.

Что и следует из толкований глаголов: compile и translate. Как ни странно - слова на английском языке тоже берутся не от балды.

Чтобы доказать истинность или ложность вики перефразируем определение в вопросительной форме:
является ли "сборка программы, включающая трансляцию всех модулей программы, написанных на одном или нескольких исходных языках программирования высокого уровня и/или языке ассемблера, в эквивалентные программные модули на низкоуровневом языке, близком машинному коду" компиляцией?

То есть, можно ли назвать это действие/процесс (а на самом деле - совокупность процессов) компиляцией?
Конечно можно, такой вариант существует. Значит вики не врёт.

Далее рассуждаем.
Раз существуют компиляторы не в низкоуровневые языки, что противоречит вики, и, при этом, вики не врёт, значит вики содержит неполную информацию. Причём неполную информацию содержит только русская вики, потому что в английской всё в порядке:
1) "The name compiler is PRIMARILY used..." (primarily фактически означает "данное определение не является строгим")
2) "A program that translates between high-level languages is usually called a source-to-source compiler or transpiler". (Тут видим упоминание о компиляторах-транспиляторах.)

Пох подставил под сомнение статью, потому что она не описывает различные варианты, про которые он знает, потому что у него есть опыт. Зато статья про транспилятор дополняет статью про компилятор.

Что тут добавить. Не стоит основываться на одном источнике информации. Или даже массе источников, если они повторяют одно и то же.

---------------

Насчёт противоречий. Подумал, и решил сделать ещё пару противоречий к резюме предыдущего сообщения (чтобы жизнь мёдом не казалась) :)

1) компиляция != трансляция - процессы разные, трансляция выполняется внутри компиляции
2) компиляция == трансляция - на выходе компиляции - оттранслированный код. Поскольку трансляция выполнилась внутри компиляции, то можно считать трансляцию подпроцессом и синонимом компиляции

3) компилятор == транслятор - компилятор выполняет трансляцию в процессе компиляции
4) компилятор != транслятор - целое не является частью самого себя (высказывание работает не всегда!).

Поразмышляй над ними. Как поймёшь разницу, тогда выйдешь на другой уровень понимания. А лучше сам напиши какой-нибудь компилятор-транслятор.
Это как смотреть на картинку, где нарисована одновременно старуха и молодая девушка. А некоторые люди могут видеть что-то одно, пока не попробуют смотреть по-другому. И трудно объяснить, как надо смотреть.

P.S. Сайт уже скукожился. Давай закругляться :) А то уже надоело заниматься т(а)(у)фтологией (выбрать подходящее)
Всё равно дальше я могу лишь предыдущие сообщения цитировать.

Удачи в осознании разницы! Практического смысла для программиста в ней нет, но хоть не будешь пытаться доказать недоказуемое. А я выхожу из дискуссии.

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

121. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 11-Апр-19, 01:17 
>компиляция не требует обязательного результата в виде машинно-ориентированного языка

где на странице в вике о компиляторе это написано? там строго утверждено - результат в виде машинно-ориентированного языка.

>A source-to-source COMPILER

Это уже противоречие, потому-что COMPILER это source-to-opcodes по определению в самой же вики на странице компилятора.

>Но обычным редактированием это не назовёшь.

Из вашего же определения выходит, что "редактирование" как следствие компиляции. У вас все есть компиляция.

>Это не противоречие, а дополнение.
>Включи логику уже. :)

Дополнение к чему? когда под гребенку компиляции можно и редактирование кода пихнуть?

>И правильно, компиляция не занимается переводом в машинно-зависимый код, что ты утверждаешь, ссылаясь на это определение. А где же речь о компиляции? А она в оставшейся части:

"""
Компили́ровать — проводить трансляцию машинной программы с предметно-ориентированного языка на машинно-ориентированный язык
"""

>Раз существуют компиляторы не в низкоуровневые языки, что противоречит вики, и, при этом, вики не врёт, значит вики содержит неполную информацию.

Отличная логика, раз существует то, что противоречит определению, значить это должно считаться дополнением к определению? Вот я вам и привел в пример, что по вашей логике и редактирование кода есть компиляция. И весь прикол в том, что если не принимать строгого определения понятия компиляции, то под гребенку компиляции можно дополнить всё что угодно.

Про  "раз существует" замечу, коментом выше указал, вы читали раздел History по ссылке source-to-source COMPILER? Извратить (дополнить) можно всё, а смысл тогда в строгих определениях?

>"The name compiler is PRIMARILY used..." (primarily фактически означает "данное определение не является строгим")

PRIMARILY - в основном, и это утвердительно, строгое определение.

>"A program that translates between high-level languages is usually called a source-to-source compiler or transpiler". (Тут видим упоминание о компиляторах-транспиляторах.)

вот оно что, так речь пошла уже о совсем другом процессе? поэтому придумали новый термин транспайлер, ибо термин компайлер в связке с source-to-source противоречит определению понятия компайлер?


>Пох подставил под сомнение статью, потому что она не описывает различные варианты, про которые он знает, потому что у него есть опыт.

Я что-то от него не услышал про те самые варианты про которые он знает (у него есть опыт? пусть поделится, буду только благодарен).

>Зато статья про транспилятор дополняет статью про компилятор.

Когда я говорил, что source-to-source это банальная трансляция, Пох говорил что компиляция, а выяснилось в итоге, что это транспиляция какая-то.

>1) компиляция != трансляция - процессы разные, трансляция выполняется внутри компиляции

Если разные процессы, то и сравнивать их незачем. Но в моем мнении именно последний этап трансляции включается в процесс компиляции. Все предыдущие - нет.


>4) компилятор != транслятор - целое не является частью самого себя (высказывание работает не всегда!).

https://ru.wikipedia.org/wiki/%D0%9F%D0%...

>Поразмышляй над ними. Как поймёшь разницу, тогда выйдешь на другой уровень понимания. А лучше сам напиши какой-нибудь компилятор-транслятор.

На пенсии займусь как раз этим, ща по времени никак.

>Это как смотреть на картинку, где нарисована одновременно старуха и молодая девушка.

здравомыслие должно иметь место всегда.

>Удачи в осознании разницы!

Лучше уж истины, и вам того же.


Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

60. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним (60), 07-Апр-19, 07:06 
> пс: цитата из вики, для особо одаренных

Вообще-то "Вики" сама суть результат компиляции (com-pile дословно "в одну кучу").

> "Компили́ровать — проводить трансляцию машинной программы с предметно-ориентированного
> языка на машинно-ориентированный язык"

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

79. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Аноним84701 (ok), 07-Апр-19, 17:35 
> )))) пройдите по ссылке указанной выше, и вовсе не компиляция, а трансляция (кодогенерация)

Выше по ссылке
https://github.com/project-everest/hacl-star
> All our code is written and verified in F* and then compiled to C via the KreMLin tool.

Еще используется "extraction"
> HACL* relies on F* (stable branch) and KreMLin (stable branch) for verification, extraction to OCaml (specs/) and extraction to C (code/).

https://github.com/FStarLang/kremlin/
> KreMLin is a tool that extracts an F* program to readable C code.
> This work has been formalized on paper. We state that the compilation of such F* programs to C preserves semantics. We start from Low*, a subset of F*, and relate its semantics to CompCert's Clight.

Очевидно, что авторы не пользуются терминологией с явно выраженным различием между "translation" и "compilation", поэтому прискипывание к конечной формулировке (тем более, после перевода) вряд ли что-то даст в конечном результате (т.е. вне опеннета).

Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

50. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от пох (?), 06-Апр-19, 23:07 
> Автоматическая генерация кода на одном языке из исходников на другом с потерей
> человекочитаемости

вы только в википедию этот бред теперь не пишите вместо того, который там уже, пожалуйста.

код там вполне человекочитаем - читавшие вон даже решили что куда более, чем код, наляпанный человеками, образующий нынешнюю линуксную crypto library. Он просто не человеком написан.

В общем-то, и выхлоп gcc -S тоже вполне человекочитаем, а что там нечеловеческая фигня написана - так она в общем-то и в исполняемом коде такая же и остается ;-)
Видимо, gcc по мнению адептов викивракии тоже "не компилятор".

> называется компиляцией. Выходной язык не обязан быть машинным кодом.

а последняя фраза верная. Собственно, вон есть такой прекрасный llvm - производит он нечто примерно такое: http://llvm.org/docs/LangRef.html#module-structure - никакая "машина" (в том смысле, в котором поняли бы современники термина "машинный код") ЭТО не исполняет, ни в текстовой форме, ни в какой либо другой. (человекочитаемым, на мой взгляд, это тоже не является, но это кому как. Лично я уж лучше выхлоп gcc -S читать буду)

Ответить | Правка | К родителю #40 | Наверх | Cообщить модератору

66. "Новая криптографическая библиотека EverCrypt с математически..."  +1 +/
Сообщение от myhand (ok), 07-Апр-19, 11:11 
> вы только в википедию этот бред теперь не пишите вместо того

Почему-ж?  В помойку надо складать мусор, она для того и предназначена.

Ответить | Правка | Наверх | Cообщить модератору

101. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от meantraitor (?), 08-Апр-19, 15:59 
> Собственно, вон есть такой прекрасный llvm - производит он нечто примерно такое:
> http://llvm.org/docs/LangRef.html#module-structure - никакая "машина" (в том смысле, в котором
> поняли бы современники термина "машинный код") ЭТО не исполняет, ни в текстовой форме, ни в
> какой либо другой. (человекочитаемым, на мой взгляд, это тоже не является, но это кому как.
> Лично я уж лучше выхлоп gcc -S читать буду)

Вы сравниваете ежа с ужом. По ссылке, которую вы привели, описана текстовая сериализация
внутреннего представления (IR) компилятора. Из gcc что-то подобное тоже можно выковырять
и вряд ли оно вам больше понравится.
Хотите сравнивать - сравнивайте clang -S vs. gcc -S.
Чтоб вы знали - эта фича (сериализация/десериализация IR в/из текста) - одна и немногих
реально крутых и полезных фич. Если это вам кажется нечеловекочитаемым - не читайте, оно не
для вас предназначено.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

111. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от пох (?), 08-Апр-19, 23:10 
> Вы сравниваете ежа с ужом.

вы, похоже, не владеете темой.

Вся суть проекта llvm - что вот это вот "внутреннее представление" и есть результат работы его компиляторов. Фронтэнды именно llvm и производят, из любого языка.
А binary targets обеспечиваются на следующем этапе, backend'ом. Причем наличие у бэкэнда asm printer'а - желательная, но совершенно необязательная фича, и совершенно параллельная binary emitter (так что еще и не факт, что на любой платформе -S вообще работоспособен)

> Из gcc что-то подобное тоже можно выковырять

у gcc, afaik, это именно сугубо внутреннее даже не "представление", а состояние компилятора, причем каждого отдельное - выковырять может и можно, но обратно запихать невозможно, и уж тем более у них нет никакого формального "language reference" для этого представления, оно языком вообще не является.

А здесь это именно язык llvm. Но совершенно нечеловекочитаемый, даром что похож.

Ответить | Правка | Наверх | Cообщить модератору

124. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от meantraitor (?), 12-Апр-19, 13:00 
> вы, похоже, не владеете темой.

Да-да, уже 15 лет не владею ;)

Все современные компиляторы так устроены уже давно - фронтенды производят IR (intermediate
representation), который уже далее обрабатывается middleend'ом и/или backend'ом.
И, кстати, этих IR'ов может быть несколько в одном и том же компиляторе

И gcc и llvm именно так и устроены.
Как я вам уже сказал, отличие llvm в том, что этот IR из него можно вытащить, а можно и запихать
обратно в текстовом виде. Заодно llvm включает в себя байткод-интерпретатор, который умеет этот IR (двоичный, не тесктовый!) исполнять и JIT.

Что касается asm printer и binary emitter, то чаще все-таки бывает, что target умеет -S, но не умеет сразу .o, чем наоборот.

То, что вы называете "состоянием" gcc - это тоже IR, и не важно, что его нельзя вытянуть из компилятора. Точнее, обычно IR таки можно достать из всех компиляторов - в двоичном виде.
(Все эти временные файлы, которые компиляторы могут производить - это он)
И обратно его потом можно засунуть. Но только в llvm к нему приделали текстовое представление.
Сравните clang -emit-llvm -S vs. clang -emit-llvm -c

> А здесь это именно язык llvm. Но совершенно нечеловекочитаемый, даром что похож.

Еще раз - этот "язык", а на самом деле сериализованный IR, не предназначен для чтения
людьми, а исключительно для писателей компиляторов. А для этих "нелюдей" исключительно удобно
- иметь возможность достать IR, покрутить его и запихнуть обратно. Или, например, regression
tests на нем писать.
Не знаю, что там такого ужасно нечитаемого в самом представлении как таковом.
Большая часть нечитаемости происходит из-за того как они variable renaming делают для SSA

Ответить | Правка | Наверх | Cообщить модератору

42. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от пох (?), 06-Апр-19, 20:54 
перепись безграмотных "программистов" на опеннете...
Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

46. "Новая криптографическая библиотека EverCrypt с математически..."  –1 +/
Сообщение от Sw00p aka Jerom (?), 06-Апр-19, 21:13 
отмазки одни, давай по делу
Ответить | Правка | Наверх | Cообщить модератору

102. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от meantraitor (?), 08-Апр-19, 16:03 
Тут он все правильно сказал.
Я сначала смеялся, потом плакал, под конец уже кровавыми слезами.
Никто не в теме, а устроили срач с видом специалистов.
Ответить | Правка | Наверх | Cообщить модератору

107. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от Sw00p aka Jerom (?), 08-Апр-19, 20:16 
чаво он там правильного сказал? У него трансляция с одного исходного языка на другой исходный язык - называется компиляцией.
Ответить | Правка | Наверх | Cообщить модератору

100. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от meantraitor (?), 08-Апр-19, 15:42 
> о, очередной "программист" самоучка? Компилятор с F на C - вполне себе компилятор, и код этот -
> компилированный. Что тебе бы рассказали на первом курсе института, если бы ты его посещал.

Вы бы, это, поаккуратнее с подобными безаппеляционными высказаваниями.
Ни разу это не компилятор, а (source-to-source) транслятор

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

115. "Новая криптографическая библиотека EverCrypt с математически..."  +/
Сообщение от t_ (?), 09-Апр-19, 01:42 
Он тоже прав. :)
Просто он имеет в виду компилятор, внутри которого работает source-to-source транслятор.
Например, так:

pkg search vala
vala-0.40.11,1                 Programming language and compiler that converts Vala code into C code

Иными словами, процессы компиляции и трансляции различаются. Но все они работают внутри компилятора (интерпретатора).

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру