LINUX.ORG.RU

Zig 0.8

 , ,


2

5

После 7 месяцев работы и 2711 коммитов вышла новая версия Zig: 0.8

Zig это:

  • Современный компилятор С

  • Современный компилятор С++

  • Компилятор языка Zig

  • Сборочная система для C, C++, языка Zig

  • (Планируется) Пакетный менеджер для С, C++, языка Zig

Zig разрабатывается под лицензией MIT: https://github.com/ziglang/zig/blob/master/LICENSE

Язык Zig – это язык общего назначения, который старается быть простым. Нет макросов, скрытых аллокаций, скрытого потока управления.

Небольшая заметка, которая пытается объяснить зачем нужен Zig, когда уже есть C++, D, и Rust: https://ziglang.org/learn/why_zig_rust_d_cpp/

Даже если вам не интересен язык Zig, возможно вам будет интересен Zig как кросскомпилятор С или С++.

#include <iostream>
int main() {
    std::cout << "Hello World!\n";
    return 0;
}
$ zig c++ -o hello hello.cpp -target riscv64-linux
$ qemu-riscv64 ./hello
Hello World!

Ещё про использование zig как кросскомпилятора: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html

В новой версии:

  1. Обновление LLVM до LLVM 12.

  2. Поддержка arm64 macOS (aka the Apple Silicon) и также поддержка кросскомпиляции C, C++, и Zig в arm64 и x86_64 macOS.

  3. Zig также разрушает миф, что вам нужен Mac и Xcode для компиляции кода для Mac OS. Заголовочные С файлы Apple выложены под Apple Public Source License которая разрешительная.

Так что вы можете собирать бинарники для Apple из-под Linux/Windows/FreeBSD без XCode:

#include <iostream>

int main() {
   std::cout << "Hello World!\n";
}
$ zig c++ main.cpp -o test -target x86_64-macos
$ file test
test: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>

Подробнее: https://ziglang.org/download/0.8.0/release-notes.html#macOS-Support

и

https://github.com/ziglang/fetch-them-macos-headers

  1. Добавлена поддержка WASI libc

  2. Начальная поддержка Haiku

  3. Изменения в языке: https://ziglang.org/download/0.8.0/release-notes.html#Language-Changes

  4. Изменения в стандартной библиотеке: https://ziglang.org/download/0.8.0/release-notes.html#Standard-Library

  5. Zig поддерживает Position Independent Executables, даже когда компилируются статические бинарники

  6. Изменения в сборочной системе: https://ziglang.org/download/0.8.0/release-notes.html#Zig-Build-System

  7. Обновление musl до 1.2.2, mingw-w64 до 9.0.0, возможность нацеливания glibc 2.33

Полный список изменений: https://ziglang.org/download/0.8.0/release-notes.html

>>> Официальный сайт

★★★★★

Проверено: Satori ()
Последнее исправление: xaizek (всего исправлений: 6)

Ответ на: комментарий от anonymous

Про стоимость вывода 1 кг полезного груза на околоземную орбиту расскажешь?

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

X512 ★★★★★
()
Ответ на: комментарий от aist1

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

Чего не хватает в https://ziglang.org/documentation/0.8.0/#toc-Memory ?

Я бы хотел иметь объекты-миксины, которые с несколькими указателями this, чтобы не быть ограниченным правилом локальности данных объекта.

В zig указатель this передаётся явно. Можешь передавать любое поле.

monk ★★★★★
()
Ответ на: комментарий от X512

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

На что жить? Из чего строить? Откуда энергию брать будут?

Для справки, космос - примущественно пустое пространство, вакуум.

anonymous
()
Ответ на: комментарий от anonymous

На что жить?

Роботы могут свои деньги выдумать. Или свой метод планирования хозяйства.

Из чего строить?

Из астероидов и ресурсов, добытых с космических тел с малой гравитацией.

Откуда энергию брать будут?

Солнечные батареи в открытом космосе работают намного эффективнее, чем на Земле. Можно ещё строить атомные реакторы из ресурсов в пункте 2.

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от X512

Годно.

По (2) у меня есть наработки в рамках Мемории — компактные квадратурные деревья (очень похожие на Quad Tree). 2 бита на узел. Кодируют разбиентие пространства на подпространства. Логарифмическое время проекции по нескольким координатом. Динамическое обновление (тоже logtime). В репе их пока еще как отдельных контейнеров нет.

По (5) ты говоришь о т.н. самоприменимых алгоритмах. Идея верная и её нужно обобщать до «оператора самоприменимости», а так же до «самоприменимых структур данных». Я тут говорю больше метафорами, но идея довольно простая. Самоприменимая Машина Тьюринга (СМТ) — это машина с отдельной лентой, на которую записываются состояния и переходы (подмножество их), т.е. обычный лог (+ поисковые индексы). СМТ может читать этот лог и учитывать его в выборе действий.

В пользу (5) говорит еще и то, что по одной из теорий из neuroscience, сознание — это воспоминание. Т.е. то, что мы в настоящий момент «переживаем» реально случилось на несколько сотен миллисекунд раньше и уже «в памяти». Это сильное упрощение, но просто для идеи.

Приколькое ответвление состоит в том, что мы уже активно пишем логи и используем эти записи для actions. Вопрос в том, могут ли такие системы в один прекрасный момент спонтанно стать self-aweare через этот лог. Вопрос шутливый, но это пока что.

aist1 ★★★
()
Ответ на: комментарий от monk

Чего не хватает

Раскладок (мэппинг) данных по памяти на локальном уровне. Распределение полей по объекту, элементов по массиву и т.д. Не так, чтобы это можно было сделать в С-стиле, а мне нужны обобщенные механизмы. Например, мне нужны эластичные древовидные (вложенные) раскладки. Мне нужны base-relative поинтеры на объекты, чтобы можно было mmap-ить структуры данных в другие адресные пространства (IPC, акселераторы и т.п.).

Можешь передавать любое поле.

Всё могу. И С++ всё это мне позволяет накостылять сверху. Но хочется в языке first class.

aist1 ★★★
()
Ответ на: комментарий от aist1

Я ещё делал некоторые эксперименты с ИИ. Делал универсальный солвер задач сформулированный в терминах пространства состояний, начального состояния, набора действий, доступных в определённом состоянии и функции оценки достижения результата для состояния. Солвер хранит дерево поиска код состояния -> объект нод состояния. Нод хранит указатель на предыдущее состояние. Поиск происходит методом вроде A* (опционально можно дать эвристику расстояния от текущего состояния до результата).

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

Также делал универсальную структуру данных для кодирования чего угодно. Она состоит из нодов, условно называемых «словами» по историческим причинам, каждое слово имеет набор свойств, ключом и значением которых также выступают слова. Значение свойства можно получить по ключу, например #1[#2] -> #3, где #1, #2, #3 – слова. Сами слова имеют только уникальный номер, их можно только сравнивать на равно/не равно. Есть таблица корневых слов, через которые происходит обращение ко всему. Слова собираются сборщиком мусора, если на них нет пути из корневых слов.

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

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 3)
Ответ на: комментарий от X512

Годно.

Я в ИИ сфокусирован на двух вещах. Это Сильный ИИ (математика и философия) и GOFAI в виде различных солверов задач комбинаторной оптимизации и программно-аппаратных акселераторов для этого. Полезность ИИ определяется не тем, как он позволяет пиццу заказывать. А тем, как эффективно он позволяет расписания строить.

В практическом плане я занимаюсь дата-уровнем. Эти самые структуры данных (2), о которых ты говорил.

aist1 ★★★
()
Ответ на: комментарий от monk

Вдогонку про нативную поддержку продвинутых раскладок памяти. Приведу пример.

У меня в Мемории есть b-tree-подобные структуры данных в узлах которых я с помощью TMP располагаю простые иерархически вложенные в линейный сегмент памяти контейнеры в SoA-формате. Эти контейнеры эластичны, что позволяет мне, например, добавлять в и уладять записи из блоков. Все это неплохо эмулируется над POD/SL-типами С++, но я не уверен, что компилятор при этом создает оптимальный код. Потому что прямая работа с памятью в С++, вообще говоря, это UB, потому что aliasing, и приходится компилятор «уговаривать», что я тут понимаю, что делаю.

Вот только я после таких «уговоров» не уверен, что он оптимальный код генерит. Надо выяснять. Даже если нет, я могу помпилятор пропатчить, чтобы он генерил.

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

aist1 ★★★
()
Ответ на: комментарий от aist1

Все это неплохо эмулируется над POD/SL-типами С++, но я не уверен, что компилятор при этом создает оптимальный код. Потому что прямая работа с памятью в С++, вообще говоря, это UB

А почему не массив байт с функциями доступа к «полям» по смещению?

monk ★★★★★
()
Ответ на: комментарий от monk

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

Более правильно считать сложность как размер компилятора/интерпретатора + размер программы для вывода строки, у того же Цейтина для вычисления числа омега так и делается.

anonymous
()
Ответ на: комментарий от aist1

А вот обратно — нет.

Ой.

Да, надо делать жуткую порнографию типа

int f1() { 
  int r;
  memcpy(data + ref_f1, &r, sizeof(r));
  return r;
}

P.S. Но capnproto посмотри. Там вроде эту проблему как-то решили.

monk ★★★★★
()
Ответ на: комментарий от anonymous

размер компилятора/интерпретатора

Так целевой язык (в который надо компилировать или на котором интерпретировать) не определён.

monk ★★★★★
()
Ответ на: комментарий от monk

А никак ты её не решишь, кроме как использования неофициальных инструментов объявления начала нового лайфтайма объекта типа memcpy или union, или bit_cast в C++20.

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

Я, правда, не уверен, что сейчас есть хоть какая-то проблема с этим. Нужно смотреть. Но потенциально, «в будущем» — да, есть.

aist1 ★★★
()
Ответ на: комментарий от aist1

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

Разве изначально от них отказывались?

Мне кажется, что просто урезали объём фич. Может быть и правда изначальный дизайн и/или реализация усложнили добавление числовых параметров - тут я не в теме. Но из количества времени до реализации фичи это, само по себе, не следует.

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

DarkEld3r ★★★★★
()
Последнее исправление: DarkEld3r (всего исправлений: 1)
Ответ на: комментарий от DarkEld3r

Разве изначально от них отказывались? Мне кажется, что просто урезали объём фич.

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

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

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

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

Если я прав про вывод типов выше, то тут дело не в компиляторе уже. Они изначально ограничили систему типов в угоду академической надежности и получили преждевременную оптимизацию.

Языки, изначально by design ограниченные в чем-то ради простоты, неизбежно попадут в ловушку этой простоты, если станут популярны. В Rust приходят плюсовики и начинают просить фичи, к которым они привыкли. И, рано или поздно, они своего добьются.

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

aist1 ★★★
()

Что за бред уже страницы две?
Вообщем где-то так

командующий 13 й армией генерал майор Голубев так же пригоден к исполнению своей должности, как дятел для передачи телеграфных сообщений. 
anonymous
()
Ответ на: комментарий от aist1

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

Не так страшен C++, как плюсовики. Разработчики языков, которые внедряют эти фичи, сами не понимают, что делают. Так как сложный язык перестаёт быть понимаемым и разработка на нём сводится к поиску заклинаний (этих ваших несжимаемых колмогоровских строк).

Выход тут либо в динамической типизации, либо в синтезе нескольких простых языков. У обычного си это есть в виде указателей на void и языка макросов. Поэтому плюсы и не могут победить си, он спокойно живёт без этих плюсовых фич. У C# тоже есть такое - Object, LINQ, аннотации.

Kogrom
()
Ответ на: комментарий от Kogrom

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

Ну, в целом, да. Согласен. Это встроенные DSL и возможность размечать в тексте программы (инлайнить) структуры данных, типа json, но не ограничиваясь им. Значительная часть сложно воспринимаемых вещей возникает именно там, где возникает высокоуровневая семантика, плохо сводимая к семантике хост-языка. Попробуем, например, размечать UI сеттерами/геттерами и ручным созданием объектов. Единственное, что это не решит проблему вообще, а только отсрочит её, если говорить о программировании «в большом».

И тут я хочу отметить, что это не проблема С++ как такового. Он «так плох» только с сравнении с другими языками там, где они оказываются «хороши», потому что дизайнились специально для этих кейсов, учитывая уже опыт ошибок своих предшественников.

Но стоит только выйти за рамки той статистики, для которой язык дизайнился, то начнет работать теорема об отсутствии бесплатных обедов. Она ведь совсем не только про ML. Тут все языки преврятятся в нечитаемую кашу и будут смотреться одинаково плохо.

Единственное, что можно сделать — это привлекать вычислительные бюджеты для «аналитики над кодом» — преобразований, позволяющих облегчить его понимание человеком в контексте разработки. И в этом плане синтаксис языка (и систему абстракций) хорошо бы делать удобной для аналитики. Ну и платформа разработки должна эту аналитику позволять делать. В Clang много чего есть интересного, но оно пока на уровень платформы не выведено и близко.

У Zig есть хорошая заявка на правильное метапрограммирование, что позволит решать проблему eDSL. Метафункции — это, по сути, проекто-специфические расширения компилятора. Ну, если их, конечно, специально не ограничивать. Они должны иметь возможность стартавать треды, ходить на диск и в сеть, к базам данных. Запускать солвери и потимизаторы и т.д. И чтобы это все реально работало, нужна платформа метапрограммирования. Чего я не вижу ни в Zig, ни в Circle.

aist1 ★★★
()
Ответ на: комментарий от Kogrom

Поэтому плюсы и не могут победить си, он спокойно живёт без этих плюсовых фич.

Не всё так просто. Я тут разговаривал с плюсовиками по поводу платформы метапрограммирования. Основная реакция — «а зачем?». Не потому, что они не понимают, зачем оно. Они не видят практических задач для этого. Отчасти, потому, что находятся в своем пузыре. Например, С++ не применяется для веб-программирования, поэтому задачи веб-программирования не входят в множество практичных для профессиональных плюсовиков. Они вообще для них не существуют. То же самое про С против С++. У этих языков уже сложились различные, долгосрочно стабильные, ниши. Туда, где активно применяется С, С++ не зайдет. И наоборот. И дело тут не в фичах языка, а в существенной разности в прагматике его применения. Тут в Америке люди — винтики. И каждый винтик должен сидеть в резьбе своего размера. Я очень часто слышу в свою сторону: «You wasn't assigned to do this.» Это не потому, что мне тут ничего не дают делать дальше тикетов. А потому, что менеджмент разделяет задачи довольно-таки подробно: каждый занят свои делом и обеспечен средствами для этого. Поэтому, С с С++ тут, в целом, не борятся. Последний немного теснит первый, но тут еще древнючий Кобол используется, и довольно широко.

aist1 ★★★
()
Ответ на: комментарий от aist1

У Zig есть хорошая заявка на правильное метапрограммирование, что позволит решать проблему eDSL. Метафункции — это, по сути, проекто-специфические расширения компилятора.

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

computer()
    .processor()
        .cores(2)
        .speed(2500)
        .i386()
    .disk()
        .size(150)
    .disk()
        .size(75)
        .speed(7200)
        .sata()
.end();

вместо

Processor p = new Processor(2, 2500, Processor.Type.i386);
Disk d1 = new Disk(150, Disk.UNKNOWN_SPEED, null);
Disk d2 = new Disk(75, 7200, Disk.Interface.SATA);
return new Computer(p, d1, d2);

Здесь никакого метапрограммирования пока не нужно. Здесь просто чейнинг. Но если мы хотим избавиться от лишних скобок, то можно использовать какой-нибудь Nim, который гибок в данной области. Но не уверен, что можно будет довести до вида, типа:

computer
    processor
        cores 2
        speed 2500
        i386
    disk
        size 150
    disk
        size 75
        speed 7200
        sata

Тут уже, наверное, потребуется внешний DSL. Но как показала моя практика, большинству программистов это и не нужно. Например, выражение на LINQ можно записать двумя способами (пример из википедии):

1:

var results =  from c in SomeCollection
               where c.SomeProperty < 10
               select new {c.SomeProperty, c.OtherProperty};

2:

var results =
     SomeCollection
        .Where(c => c.SomeProperty < 10)
        .Select(c => new {c.SomeProperty, c.OtherProperty});

Так вот я столкнулся с тем, что подавляющее большинство C# программистов предпочитает вторую форму.

Kogrom
()
Ответ на: комментарий от Kogrom

Тут уже, наверное, потребуется внешний DSL. Но как показала моя практика, большинству программистов это и не нужно.

Программистов больше интересует API, который упростит разработку алгоритмов, а возможности типа экономить на «;» - мало кого …

anonymous
()
Ответ на: комментарий от Kogrom

LINQ

Хороший пример, и конкретно тут дело не в синтаксисе, а в оптимизациях времени компиляции, которые можно делать метапрограммами. Например, применять запросы к произвольным объектным графам, структура которых известна во время компиляции и аннотирована дополнительными метаданными для оптимизатора. Запросы можно сразу оптимизировать так, как это делает SQL-оптимизатор, что сильно разгрузит программиста. И в рантайме, в идеале, свернуть до пары вызовов функций.

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

Чтобы декларативное программирование (eDSL) завелось, нужно иметь возможность подуключать SMT solvers, constraint solvers, theorem provers, работать многопоточно и уметь ходить к внешним источникам данных. И вот для последнего уже нужна платформа, а не просто возможность запускать код.

aist1 ★★★
()
Ответ на: комментарий от Kogrom

Почитал некоторые треды и ужаснулся.
Если предоставляю программистам API, которые предоставляет функциональность создания объектно-ориентированных систем управления данных, то мамия …
Ведь «легким движением» руки создаем а-ля файловые системы, реестры данных, графические, мультимедийные, … форматы данных, хранение ресурсов для игроделов, …

Да что угодно

Ох подумаю еще много раз прежде чем принести в СТРОЙНЫЙ и КРАСИВЫЙ и УСТОЯВШИЙСЯ десятилетиям мир ПЕРЕДОВЫХ ТЕХНОЛОГИЙ хаос …

А работа то не быстро /жара/ движется все же и ни какое иное API не буду разрабатывать до окончания разработки этого API /разве что пару аллокаторов для memory и файлов/.
anonymous
()
Ответ на: комментарий от anonymous

И эшо

А в IT все так спокойненько,
Среди Microsoft, ... вдалеке
Всё культурненько, всё пристойненько,
И решен в C++ с метаданными вопрос.
anonymous
()
Ответ на: комментарий от anonymous

Ох подумаю еще много раз прежде чем принести в СТРОЙНЫЙ и КРАСИВЫЙ и УСТОЯВШИЙСЯ десятилетиям мир ПЕРЕДОВЫХ ТЕХНОЛОГИЙ хаос …

Ой, а без тебя хаоса нет, как же!.

API, конечно же, много значит. MongoDB, как именно база данных, это что-то между так себе и никак. Но API был приятным для веба, да и сама модель данных вполне себе удобная. В результате, Mongo выграла гонку популярности у куда более продуманных решений. И постепенно, с грехом пополам, подтянула storage layer.

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

Когда ты разрабатываешь именно API, т.е. преобразование модели хранения данных в модель их представления и обработки, ты от многих (но не от всех) вещей, указанных выше, можешь абстрагироваться, сбросив это на нижележащее хранилище. А если делаешь вертикально-интегрированное решение, то всё на тебе.

aist1 ★★★
()
Ответ на: комментарий от monk

Точно. Тогда вообще 2КБ остаётся.

Кстати, на С можно получить даже 1536 байт:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

int WINAPI mainCRTStartup() {
   char msg[] = "desktop_ini.exe folder\n";
   HANDLE stdout = GetStdHandle(STD_OUTPUT_HANDLE);
   WriteFile(stdout, msg, sizeof(msg), (DWORD[]){0}, NULL);
   return 0;
}
clang -c -Oz main.c -o small_c.clang.o -nostdlib -ffreestanding -fno-stack-check -fno-stack-protector -mno-stack-arg-probe
link small_c.clang.o kernel32.lib /SUBSYSTEM:CONSOLE
strip small_c.clang.exe

С gcc у меня меньше 3584 байт не получилось создать «Hello World!» 😔

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от monk

Точно. Тогда вообще 2КБ остаётся.

Даже 1056 байт

#define WIN32_LEAN_AND_MEAN
#include <windows.h>

int WINAPI mainCRTStartup() {
   char msg[] = "Hello World\n";
   HANDLE stdout = GetStdHandle(STD_OUTPUT_HANDLE);
   WriteFile(stdout, msg, sizeof(msg), (DWORD[]){0}, NULL);
   return 0;
}
clang -c -Oz main.c -nostdlib -ffreestanding -fno-stack-check -fno-stack-protector -mno-stack-arg-probe -o main.obj
link main.obj kernel32.lib /subsystem:console /nodefaultlib /align:16 /entry:mainCRTStartup /out:main.exe

Правда выдаётся предупреждение:

LINK : warning LNK4108: /ALIGN specified without /DRIVER; image may not run

Но работает, если не делать strip.

После strip main.exe 1008 байт, но уже не запускается :(

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от aist1

@aist1 , @monk

И у нас есть победитель :)

$ cl /c /O1 /GS- main.c  
$ crinkler.exe main.obj "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x86\user32.lib" "C:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x86\kernel32.lib" /entry:mainCRTStartup /out:demo1.exe
$ demo1.exe
Hello World

Если использовать clang вместо MSVC cl, то просто крашится всё. А с MSVC всё работает.

488 байт

и llvm-size его не понимает.

llvm-size --format=sysv demo1.exe
demo1.exe  :
section     size   addr
Total          0
fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от aist1

я немного поменял параметры Crinkler и стал размер 372 байта.(по той же ссылке яндекса)

Чем смотреть секции?

Dependencies выдают: https://imgur.com/a/xyiz2r5

Но exe работает, печатает в консоль :)

fsb4000 ★★★★★
() автор топика
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от aist1
objconv -fnasm demo1.exe demo.asm

Input file: demo1.exe, output file: demo.asm
Converting from COFF32 to Disassembly32
Error 2035: Pointer out of range in object file
Error 2016: Index out of range

сайт вернул Internal Server Error

llvm-objdump --all-headers demo1.exe

demo1.exe:      file format coff-i386

architecture: i386
start address: 0x00000064

llvm-objdump.exe: error: 'missing data dir for TLS table': demo1.exe
fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от aist1
Сплошной ГОЛЛИВУД: нет ни Марса, ни Венеры, ни Солнечной Системы практически.
trait Grace {  
    fn new() -> Self
        where Self : Sized;
}

fn grace<T:?Sized+Grace>(t: &T) {
    let grace: T = Grace::new();
}

Глаголет свидетелствуяй сия бывший Лорд-наместник Норфолка @T-1000

anonymous
()
Ответ на: комментарий от fsb4000

Ну ты что-то тогда такое жуткое призвал своими заклинаниями, шаман!

Сейчас я попробую в линуксе такое призвать.

aist1 ★★★
()
Ответ на: комментарий от fsb4000

Взял отсюда. Канпелял с твоими ключами.

victor@victor-X570:~/cxx$ objdump -ds syscall_hw 

syscall_hw:     file format elf64-x86-64

Contents of section .note.gnu.build-id:
 400158 04000000 14000000 03000000 474e5500  ............GNU.
 400168 b336fb91 0d878ec0 8d89eb29 5b8a7974  .6.........)[.yt
 400178 030bae27                             ...'            
Contents of section .text:
 401000 48b8776f 726c6421 0a00488d 7424f048  H.world!..H.t$.H
 401010 89460748 b848656c 6c6f2c20 77488906  .F.H.Hello, wH..
 401020 48b80100 00000000 0000bf01 00000048  H..............H
 401030 ba0e0000 00000000 000f05b8 3c000000  ............<...
 401040 0f05                                 ..              
Contents of section .rodata:
 402000 48656c6c 6f2c2077 6f726c64 210a00    Hello, world!.. 
Contents of section .comment:
 0000 5562756e 74752063 6c616e67 20766572  Ubuntu clang ver
 0010 73696f6e 2031322e 302e312d 2b2b3230  sion 12.0.1-++20
 0020 32313036 32353036 32363236 2b303732  210625062626+072
 0030 33346337 64366263 322d317e 65787031  34c7d6bc2-1~exp1
 0040 7e323032 31303632 35303433 3335332e  ~20210625043353.
 0050 31323500                             125.            

Disassembly of section .text:

0000000000401000 <.text>:
  401000:	48 b8 77 6f 72 6c 64 	movabs $0xa21646c726f77,%rax
  401007:	21 0a 00 
  40100a:	48 8d 74 24 f0       	lea    -0x10(%rsp),%rsi
  40100f:	48 89 46 07          	mov    %rax,0x7(%rsi)
  401013:	48 b8 48 65 6c 6c 6f 	movabs $0x77202c6f6c6c6548,%rax
  40101a:	2c 20 77 
  40101d:	48 89 06             	mov    %rax,(%rsi)
  401020:	48 b8 01 00 00 00 00 	movabs $0x1,%rax
  401027:	00 00 00 
  40102a:	bf 01 00 00 00       	mov    $0x1,%edi
  40102f:	48 ba 0e 00 00 00 00 	movabs $0xe,%rdx
  401036:	00 00 00 
  401039:	0f 05                	syscall 
  40103b:	b8 3c 00 00 00       	mov    $0x3c,%eax
  401040:	0f 05                	syscall 

Размеры секций:

victor@victor-X570:~/cxx$ llvm-size-12 syscall_hw 
   text	   data	    bss	    dec	    hex	filename
    117	      0	      0	    117	     75	syscall_hw

aist1 ★★★
()
Ответ на: комментарий от fsb4000

В другом формате:

victor@victor-X570:~/cxx$ llvm-size-12 --format=sysv syscall_hw
syscall_hw  :
section                size      addr
.note.gnu.build-id       36   4194648
.text                    66   4198400
.rodata                  15   4202496
.comment                 84         0
Total                   201

Т.е., всего 81 байт.

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

Размер файла то сколько?

Кстати, https://github.com/runestubbe/Crinkler можно использовать и для других языков.

Hello world на zig с Crinkler 486 байт. И запускается везде где я смог проверить (Win 7, Win 8, Win 10, Linux wine)

А \TINYIMPORT опасная штука у Crinkler. Экономия почти 100 байт, но запускается только на Windows 10 и Windows 7. На Win 8 и Linux wine ошибки.

/TINYIMPORT
    Enables a more compact, but less future-proof, function importing
    scheme which does not require the explicit storage of function
    name hashes. This is achieved by indiscriminately importing every
    function from the relevant DLLs. The imported functions are
    scattered in an import table based on their function name hashes.
    Intuitively, this embeds the hash code entropy directly into the
    call instruction.

Вообще линкеры много могут, не только компиляторы. Размер приложения уменьшился почти в 10 раз для HelloWorld лишь с изменением линкера c gnu ld на Crinkler с теме же объектными файлами. Даже изменение gnu ld на Microsoft link почти вдвое уменьшило размер.

Также как использование zig линкера на Linux тоже вдвое уменьшает размер относительно ld для HelloWorld.

fsb4000 ★★★★★
() автор топика
Ответ на: комментарий от fsb4000

Размер файла то сколько?

Дался тебе этот размер файла! exe - это контейнер, в него пихается много всего нужного и ненужного. Нужно смотреть на размер секций, если хочется получить представление о размере самой программы.

А размер исполнимого файла после strip у меня 8728 байт, если так уж надо. Но это ни о чем.

aist1 ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.