https://www.opennet.dev/openforum/vsluhforumID3/127181.html Представлен релиз кроссплатформенного открытого генератора сценариев сборки CMake 3.23, выступающего в качестве альтернативы Autotools и используемого в таких проектах, как KDE, LLVM/Clang, MySQL, MariaDB, ReactOS и Blender. Код CMake написан на языке C++ и распространяется под лицензией BSD...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56962<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#20 Sat, 09 Apr 2022 13:16:52 GMT &gt; Нафиг нам ваш собственный компилятор. Лучше бы в Clang поддержку добавили.<br><br>Что не понятного? Если фирма работает "армейским способом" то и результат получается харвктерный.<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#19 Tue, 05 Apr 2022 22:22:42 GMT Вообще это от кодера зависит.<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#18 Tue, 05 Apr 2022 09:14:22 GMT &gt; В чём продуктивность? <br>&gt; Если LLVM IR не очень подходит, то надо дорабатывать именно его. <br><br>Тут на opennet есть более компетентные чем я в этом вопросе товарищи, но как я понял, доделать LLVM<br>- во-первых, это всё равно, что его переделать полностью, потому что даже на ARM оно перенесено большой кровью, что уж говорить про VLIW.<br>- во-вторых, для VLIW нужен именно оптимизирующий (!!!) компилятор. Т.е. как минимум оптимизатор и кодогенерацию придётся всё равно пихать в LLVM (не заикаюсь уже про открыть).<br><br>Чем это проще, чем реализованный подход? От LLVM остаётся по-сути в виде фронтенда и генератора IR как и был, но бэкендом компиляции/оптимизации выступает LCC - собственный компилятор, который разбирает и транслирует уже в нативный код. В таком случае, всё, что реализовано поверх LLVM - остаётся в силе. Сложности с JIT-ами, там да, ибо JIT и VLIW стыкуются слабо.<br><br>&gt; Потому что иначе не видать вам для эльбрусов OpenCL и Vulkan (llvmpipe)<br><br>Ну это вряд-ли, в данном конкретном разрезе CPU безразличен. https://www.opennet.dev/openforum/vsluhforumID3/127181.html#17 Tue, 05 Apr 2022 08:11:29 GMT В чём продуктивность? Если LLVM IR не очень подходит, то надо дорабатывать именно его. Потому что иначе не видать вам для эльбрусов OpenCL и Vulkan (llvmpipe), эффективных нейросетей на CPU, декомпиляторов, рекомпиляторов и даже JIT-ускоренных ЯП-виртуальных машин. Ибо современный подход состоит в том, что всё это делается поверх LLVM и оперирует с LLVM IR.<br><br>Не адаптируя LLVM к своей платформе создатели отрезают её от экосистемы утилит на основе LLVM. Коммерчески может это и правильно, ведь можно написать своё проприетарное и продавать за деньги, и кое-кому придётся это купить. Но платформу это губит.<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#16 Tue, 05 Apr 2022 04:22:28 GMT На самом деле синтаксис у cmake проще некуда. Проблема с ним (как и с прочими утилитами подобного плана) в том, что для запоминания недостаточно практики. Пишут файлы один раз на старте проекта, а потом он просто работает. Всё забывается. Через может пару месяцев надо что-то дописать. Заглубился, дописал, опять забросил на длительный срок. Так и выходит, что каждый раз - как в первый.<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#14 Mon, 04 Apr 2022 22:08:14 GMT всем Спасибо<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#12 Mon, 04 Apr 2022 17:08:53 GMT https://www.delorie.com/djgpp/<br>https://github.com/open-watcom/open-watcom-v2<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#11 Mon, 04 Apr 2022 15:59:30 GMT Если в чистом DOS и для чистого DOS, то от Borland-а есть утилита командной строки bcc.exe, не от Borland-а можно поискать Watcom C++ - там wcc, если правильно помню, правда он уже только для Dos-extender-ов код генерирует.<br> https://www.opennet.dev/openforum/vsluhforumID3/127181.html#10 Mon, 04 Apr 2022 15:39:33 GMT Перекличку адептов Единственно Правильного Синтаксиса объявляю открытой.<br>