Bytecode and total control over VM could give a lot of benefits: easy implementation for sophisticated
profiling,
testing,
debugging

ALL without OS and processor interference. Awesome.
ALAS one should not forget that all of that is not "true" in a sense, that it's not production binary that will be debugged, tested and profiled. But still, TASTY.

Hello darkness^W hash table my old friend...
Приятно все-таки байтики теребить, как отцы теребили.

Пока писал ассемблер, осознал, что мне только заднеконечность его нужна.
Пока я был в спячке в студию завезли clang.
[x] Import section
[x] Data section
[ ] Code section
[ ] Relocation section

Если мне на этой неделе не придется идти пить, то хорошие шансы заиметь хелловорлд к воскресенью.

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

Это победа.

Завтра, после причеса хрени сверху и запила линкера, буду финализировать строки.

u8'this string will be stored in utf-8 encoding'; //since utf-8 is default and only source encoding u8 can be omitted
u16'this string will be stored in utf-16 encoding';
u32'well, you get the picture'; //правда utf-32 подождет неопределенное количество времени, ни разу не видел в дикой природе

"Таких строк" и L"таких" строк не будет (ибо ебаный костыль и дикое уебанство). Различать будем по типу:

array-of-chars : u8[] = 'array of chars in utf8 (because array is u8) encoding';
string: ptr<u8> = 'string in utf8 (has trailing zero)';
wide-string: ptr<u16> = 'you get the picture';

хм. поинтеры можно и расширить. например
ZeroTerminatedPtr<SomeSizeableType> = ValueTerminatedPtr<SomeSizeableType ~ 0>
сишные строки тогда будут иметь вид ZTPtr<u8>. Можно дать алиас cstr<u8>.
Меня понесло. Всему свое время.

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

>>15287
And off we go!

I HATE GCC
I HATE GCC
I HATE GCC
I HATE GCC!!!

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

ПИРИЗАГРУЗИ МАШИНУ - У ТИБЯ МЕЙК НИ РАБОТАИТ!!!1

Бесплатный сыр.

Поднадоела мне эта мышиная возня.

К концу недели попробую сделать.

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

И как я сразу не пропехал, что callNat можно использовать и для локальных вызовов? Всего-то надо сравнить адрес вызова с рейнджем адресов байткода. Так что мне нужно только выбрать calling convention и запилить ret инструкцию.

Алсо '--subsystem windows' не нужен - конпелятор жи конпелируем!

>>15317
Хрен ли там выбирать - очевидный stdcall очевиден. Алсо надо было сразу "эмулировать" x86 проц, а не плодить всякие GENERAL_PURPOSE_REGISTER_1. Потому что я его знаю.

absolutely disgusting.jpg

>>15299
А чего хейтить–то? Сам делаешь фигню, сам разгребаешь, всё закономерно.
http://f.osdev.org/viewtopic.php?f=1&t=28307#p238275

>>15217
Алсо, нормальные люди просто берут какой–нибудь Lua, создатели которого уже давно греблись и таки разгреблись и с utf8 и с хештейблами и с байткодами, встраивают и пользуются.

Если же конечная цель — скилл и понимание как оно устроено — уважаю, но подход очень уж наощупь. Ну и не понятно, что ты потом с этим пониманием собираешься делать…

>>15333
Тут видишь какая штука, я (как и любой другой нормальный человек) ожидал, что -nostdlib таки означает NO std lib.

>нормальные люди просто берут какой–нибудь Lua...
Нормальные люди Lua не берут, по крайней мере не для написания компилятора.

Конечная цель - писать нативный софт на языке, созданном для людей.

>>15307
Шанс не успеть к концу сегодня повысился ибо я бросил сишные исходники и переписываю на сисярпе.

>>15335
Прежде всего — define «язык, созданный для людей». Ибо «сишка с человеческим лицом», как выясняется, понятие растяжимое. Вон, Пайк и Томпсон сотоварищи тоже хотели — а получилось какое–то   Go  .

>Нормальные люди Lua не берут
Ну ок тогда, пусть будут люди ненормальные в моём лице. Изначально только «голая няшная», только хардкор. Надоело руками долбится с памятью, строками и прочая, когда нужен не столько код, сколько результат его работы — приходим к скриптам. Хотя, возможно для начала хватило бы и https://github.com/antirez/sds Перебираем кучу интерпретаторов, в поисках самого шустрого, встраиваемого и с минимальными зависимостями — находим искомое. Всё. Скрипты пишутся, критичные куски допиливаются нативными либами, датасеты парсятся, все счастливы и танцуют.

Идеи компилять компилятор и переизобретать luavm/nekovm/dalvik/тысячи_их /а то и вовсе jvm, или, упасигосподь clr так и не возникает.

>Тут видишь какая штука, я (как и любой другой нормальный человек) ожидал, что -nostdlib таки означает NO std lib.
Всё верно. Сказали «пользователь не дурак и знает что делает» — gcc честно не вкомпиливает рантайм, в том числе libgcc. Но при условии, что «любой другой нормальный человек» использует gcc на его исконно–посконной платформе, а не «gcc+набор оконных костылей» под названием mingw. И раз уж вырубает рантайм, то понимает специфику и либо не будет жрать стек, либо выкатит свою реализацию stack probing — это не приколы компилятора, это особенности окон. https://support.microsoft.com/en-us/kb/100775

>>15338
>define «язык, созданный для людей»
>>12154
>Вон, Пайк и Томпсон
Я не знаю что эти два полуебка хотели, но точно не сишкоподобное. Сишка и ГЦ понятия не совместимые.

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

>Всё верно. Сказали «пользователь не дурак и знает что делает» — gcc честно не вкомпиливает рантайм, в том числе libgcc
Ок. Я читал жопой документацию к ГЦЦ. За ссылку отдельное спасибо.

>>15338
Кстати
>упасигосподь clr
Чем он тебя так отвратил? Я вглубь не лазил и мне интересно.

>>15340
>Чем он тебя так отвратил?
Габаритами и сложностью, прежде всего. Ынтырпрайз в плохом смысле слова. Классы классов и фабрики фабрик, ООП во все поля. Типизация, объекты и эксепшены на уровне байткода. Делалось чтобы догнать и перегнать полновесную жабу, на фоне тогдашнего хайпа. Многое прибито гвоздями к x86 — а до кучи оно ещё и стековое, хоть и с родным jit. При нынешнем засилье армов и мипсов на мобильных платформах и в эмбеддед — не оче.

И всё–таки, что ты хочешь от языка? Было ли это уже где–нибудь? Реализуемо ли искомое в качестве либы или рантайма к сишечке? Или как фронтенд к llvm? Или к nekovm?

Ну и напоследок, из моей коллекции рандомных ссылок на все случаи жизни, чисто поржать: http://www.compuphase.com/pawn/pawn.htm

>>15341
>Классы классов и фабрики фабрик, ООП во все поля
Это языковые фичи так-то. Если под классами классов подразумеваются генерики, то по-другому только как в жаве - через type erasure.

>И всё–таки, что ты хочешь от языка?
Как можно более сильную типизацию, не мешающейся под ногами; при этом без рантайма и временем debug компиляции до 1MLoC проектов не более секунды (на моей машине). Язык должен быть целиком и полностью под моим контролем для оперативного впиливания/выпиливания фич.

>Было ли это уже где–нибудь?
Да наверняка, ничто не ново под Луной же. В большинстве случаев, однако, они идут в комплекте со всякими ненужностями типа ГЦ и/или ООП.

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

>Или как фронтенд к llvm?
LLVM будет backend'ом для релизных сборок. Тут без вариантов.

>Или к nekovm?
Мне настоящие ВМки не нужны. Я свою-то запилил исключительно чтобы на первых порах не разбираться с нативным байткодом.

>pawn
Что-то мне жаль стало человека - столько труда угробить. А скриншоты вызвали прилив ностальгии.

>>15342

>Это языковые фичи так-то.
У той же явы вм более низкоуровневая и гибкая. Хотя, уши x86 всё равно торчат.

>>И всё–таки, что ты хочешь от языка?
Ну, я это к тому, что начинать неплохо бы таки с диздока, плавно переходя к спекам. =)
Закодить ещё десять раз завсегда успеется.

Тем не менее, интересно что получится, ждём, будем посмотреть если таки зарелизишь.

А вообще, идея причесать сишку прям–таки витает в воздухе. И даже небо, и даже Аллах Мелкософт:
https://github.com/Microsoft/checkedc
https://github.com/Microsoft/checkedc-llvm

Exception'ы вещь плохая, а вот abortable computation может быть и нет. Правда плохо себе представляю как это запилить без мандадок.

>>15341
> засилье армов
Xamarin, mono, а скоро и .net core под Windows 10 IOT (arm)

>>15359
Этому Ксамарину лет в обед, а достиг ли он тех же фич, что и .NET на виндах?

Наканец-то можно спокойно поработать.

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

ｷﾀ━━━(ﾟ∀ﾟ)━━━!!

>>15348
syntax sugar BUT I want it to be reflected in type signature (do I?)

https://github.com/andrewrk/zig

>>12199
>Мне кажется ошибкой начинать писать цомпелятор с разбора комментариев и синтаксиса в целом. Я бы сначала с голым AST поигрался. По моему скромному опыту, так гораздо проще экспериментировать.
Подтверждаю: так действительно проще экспериментировать. Так что если очень интересно поиграться с типизацией - самое то.
К сожалению в этих креативных играх (не как что-то плохое, не подумайте. Очень занятная гимнастика для ума), можно потерять связь с "реальностью". А моя реальность такова, что а) я тупенький; б) хочу исполнимый байткод когда уже, ну сколько можно!; в) перформанс конпелятора таки важен.
Это я к тому, что взбрела мне в голову офигительнейшая, ground breaking, absolutely amazing yadda-yadda идея: заиметь типы, которые можно параметризовать не только типами, но и compile-time значениями. Зачем: чтобы можно было делать foreach. Где компайл-тайм значения, там и символы (любые синтаксически верные конструкции: числа, структуры, функции (хуле бы нет?). А где символы, там и макры. Маам! СМотри какой я лисп переизобретаю! Правда я у тебя самый умный?
Так вот, не в этом году. Я так просто заблукаю в этой вашей PLT, а мне не статьи писать, мне инструмент нужен.

tl;dr
В этом году генерики могут быть параметризированы только типами. Играться с типизацией очень занятно, рекомендую.

>>15507
Спасибо за ссылку!

0/1. Here is why:

>>Existing Features

>Compatible with C libraries with no wrapper necessary. Directly include C .h files and get access to the functions and symbols therein.
Идея "как можно более легкое переиспользования сишных либ" - хорошая. Реализовывать ее через встроенную поддержку ашников - сомнительно.
>Compile units do not depend on libc unless explicitly linked.
Good.
>Provides standard library which competes with the C standard library and is always compiled against statically in source form.
Govno. Просто потому, что все стандартные либы - говно, no exceptions!
>Pointer types do not allow the null value. Instead you can use a maybe type which has several syntactic constructs to ensure that the null pointer is not missed.
Good.
>Provides an error type with several syntatic constructs which makes writing robust code convenient and straightforward. Writing correct code is easier than writing buggy code.
Huh? looks at example Eww.
>No header files required. Top level declarations are entirely order-independent.
Good.
>Powerful constant expression evaluator. Generally, anything that can be figured out at compile time is figured out at compile time.
Это и си умеет.
>Tagged union enum type. No more accidentally reading the wrong union field.
Good.
>Generics so that one can write efficient data structures that work for any data type.
Good.
>Easy to parse language so that humans and machines have no trouble with the syntax.
THE CAKE IS A LIE.
>The binaries produced by Zig have complete debugging information so you can, for example, use GDB to debug your software.
Good.
>Debug mode optimizes for fast compilation time...
Good.
>...and crashing when undefined behavior would happen
UB не место в языке. Говно.
>Release mode produces heavily optimized code. What other projects call "Link Time Optimization" Zig does automatically.
Good.
>Mark functions as tests and automatically run them with zig test.
Eh? Нахуя?
>Supported architectures: x86_64, i386
OK.
>Supported operating systems: linux
Мусор, а не конпелятор. опять L'ой, бля, а в винде-то вот так, бабоньки! ой-ой-ой.' или автор - идейный красноглазик?
>Friendly toward package maintainers. Reproducible build, bootstrapping process carefully documented. Issues filed by package maintainers are considered especially important.
К языку/конпелятору это никаким боком.
>Easy cross-compiling.
Что во что? Линукс64 в линукс86?
>Eliminate the preprocessor, but (most) everything you can accomplish with the preprocessor, you can accomplish directly in the language.
Может быть.

>>Planned Features

>In addition to creating executables, creating a C library is a primary use case. You can export an auto-generated .h file.
Мусор.
>Eliminate the need for configure, make, cmake, etc.
Хорошо.
>Automatically provide test coverage.
Мусор.
>Ability to declare dependencies as Git URLS with commit locking (can provide a tag or sha256).
Ну а это вообще пиздец уровня "сразу нахуй". Что реклама с детьми делает, ужас!
>Include documentation generator.
Хорошо, но в компиляторе этому места быть не должно. Отдельная тулза должна быть.
>Compiler exposes itself as a library.
А, вот для чего. Ну ок.
>Support for all popular architectures and operating systems.
Мечты-мечты, где ваша сладость.

Вобщем, здравые идеи есть, но - нет.
И синтаксис говно.

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

По существу у тебя две претензии к зиг:

• нет кроссплатформенности. Непонятно, кстати, почему, у него же llvm. Но у тебя ведь ее тоже нет.
• есть UB, иными словами язык "не безопасный". Ты хочешь этим сказать, что у тебя будет что-то иное? И как же ты это реализуешь, особенно учитывая возможность вызывать сишные либы? Пример такого языка - си шарп, и там для этого сделана целая подсистема с unsafe. у тебя тоже так будет?

>>15517
Это не все претензии, я просто разобрал фичлист. Есть еще вещи в нем неописанные, которые я считаю нужными или вредными, но глубоко нырять не стал (ибо фичлиста хватило)
>нет кроссплатформенности. Непонятно, кстати, почему, у него же llvm. Но у тебя ведь ее тоже нет.
Не совсем, притензия не к отсутствию кроссплатформенности как к таковой, а к ограниченному платформенному кругозору автора. Я не зря привел пример со строками: когда пишешь под винду, все ~W функции WinAPI требуют Utf16 encoded строки. В линуксе (и в маке?) defacto стандарт - utf8, который прекрасен тем, что "строки" можно считать однобайтовыми. И сишные литералы строк как раз однобайтовые. И чтобы одно заработало под другим, нужно пердолиться макросами. Это не удобно, я когда хочу передавать/получать строки внешнему миру, не хочу ебаться с char/ushort/TCHAR и _T/L.
>есть UB, иными словами язык "не безопасный". Ты хочешь этим сказать, что у тебя будет что-то иное? И как же ты это реализуешь, особенно учитывая возможность вызывать сишные либы? Пример такого языка - си шарп, и там для этого сделана целая подсистема с unsafe. у тебя тоже так будет?
UB это просто лень (вроде четкой фиксации порядка вычисления значений параметров при вызове функции) или невозможность (если мы говорим о С как о языке для работы даже с совсем дикими архитектурами (как во времена его создания), когда у тебя bit shift может сохранять знак, а может и нет) четко описать семантику языка. UB позволяет компиляторам творить самодеятельность в таких местах, запросто вопреки ожиданиям программиста. Как видишь, к безопасности это имеет не самое прямое отношение. А к вызову либ так и совсем никакого :)
Моя задача задизайнить язык так, чтобы никаких темных пятен не было. Все должно быть четко и полностью определено, без возможности вольного трактования. Из-за чего кстати, я буду ограничен исключительно x86_64 архитектурой.
Unsafe не будет - весь код один большой unsafe. Моя задача заиметь систему типов, которая бы позволяла и проверять себя на глупость (запрет на арифметику и dereferencing для nullable pointer) и отстреливать себе ноги (not-null! оператор магическим образом преобразует nullable pointer в non-nullable).

Но поверх всего этого - скорость компиляции и качественные сообщения об ошибках. Они имют топовый приоритет.

>>15526
Спасибо за разъяснения. У тебя хорошая, солидная платформа. Надеюсь увидеть spice в рабочем состоянии.

>>15526
>UB это просто лень (вроде четкой фиксации порядка вычисления значений параметров при вызове функции)

Непорядок вычисления параметров - это не unsafe и не UB. Код, который зависит от порядка вычисления параметров - это говнокод. Представь себе, что у тебя есть две функции - одна принимает данные в одном порядке ,а другая - в другом, а у тебя в параметрах побочкные эффекты. Баги полезут резво, а детектить этокомпилятором чуть ли не невозможно. UB - это форматирование жёсткого диска в ответ на деление на ноль, например.

И что-то я не понимаю, как ты будешь делать unsafe (т.е. программа может стрелять себе в ногу) без UB. Это возможно только в двух случаях:

• ты покрываешь всю программу неявными проверками каждого указателя/разыменования (это если у тебя unsafe только с указателями связан), и тогда скажи пока производительности
• ты исполняешь программу в виртуалке на bare metal

Или ты считаешь крах программы по access violation well-defined? Тогда ты привязываешься к операционке/ядру, и твоя программа - это программа+ОС.

>>15533
Есть UB и есть UB: http://blog.regehr.org/archives/213
http://blog.regehr.org/archives/226
http://blog.regehr.org/archives/232

>Или ты считаешь крах программы по access violation well-defined?
/0 is execution environment dependent. Может, не очень well, но хотя бы не "да делай что хочешь, конпелятор!"

>>15533
>Тогда ты привязываешься к операционке/ядру, и твоя программа - это программа+ОС
Ты и так к ним привязан, поскольку пользуешь их API. Кроссплатформенность это миф.

>>15538
>Кроссплатформенность это миф.

Well-defined-поведение - это и есть кроммплатформенность.

>>15537

Ты только про одно забыл: вот например перезапишешь ты стек каким-нибудь мусором, программа бдет дальше работать, ошибки нет. Потом она всё-таки вылетит, а целостность данных уже всё.

Поэтому эксепшены - это полдела.

>>15539
>Well-defined-поведение - это и есть кроммплатформенность.

Ну, то есть, well-defined и не implementation-defined.

>>15539
Не забыл, от этого в языке, позволяющим ассемблерные вставки и прямую работу с памятью никак не уйти. Или так или "джава". Я повторюсь: "Все должно быть четко и полностью определено, без возможности вольного трактования", и уточню: "...трактования компилятором".

>>15546

Я, честно говоря, всё равно не понимаю, зачем тебе определять всё желаемое поведение программы, если оно полетит к чертям из-за первой же ошибки в unsafe-коде.

>>15556
Он выше приводил ссылки на три блог поста, где подробно эта тема освещена.

>>15557

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

В совмещении с языком C/C++ и ассемблерными вставками эти сетования выглядят лицемерно.

>>15585
Я не ОП, но согласен с его подходом. В том блоге объясняется, что UB существует в стандарте только по одной причине: чтобы позволить писателям компиляторов делать оптимизации. Если ты не ставишь перед собой такую задачу, то нет никаких причин оставлять белые пятна в языке. В случае языка ОПа, который в обозримом будущем будет иметь дай Бог одну реализацию, он может просто сделать удобную для себя спецификацию. От всех напастей небезопасного кода тебя это не спасет, но то что написано на самом языке будет иметь хорошо определенное поведение.

>>15586

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

>>15591
>арифметики указателей

>>15586
Вообще, разумеется, пилить свой велосипед всегда хорошо и интересно, просто мне хотелось бы понять, хочет ли ОП чего-то, кроме того, чтобы ошибки в программе проявлялись в предсказуемом виде (и с арифметикой это невозможно).