Интересно, а что там удалось оптимизировать именно на Ассемблере, чего нельзя сделать на Си? Система крайне интересная, но как уже заметили в комментариях — совершенно непереносимая, а в современном мире наибольший интерес представляют такие системы именно для ARM. В связи с этим было бы крайне интересно ознакомиться с каким-то анализом кодогенерации… возможно там есть какие-то особенности, которые были бы крайне интересны с точки зрения расширения возможностей языка Си или создания нового низкоуровневого языка, компиляция с которого по крайней мере в контексте MeOS давала бы результаты не хуже Ассемблера.
Это круто. Я к сожалению не математик, но интуитивно понимаю, что это исключительно правильное направление движения. Компьютеры должны уметь обращаться с информацией на как можно более глубоком семантическом уровне, а не просто гонять по сети гигабайты «человекоориентированного» видео, которое для самих компьютеров по сути информационный шум.
Вот когда подобным образом будет оцифрована не только математическая информация, но и информация из множества других областей знаний, тогда и наступит Сингулярность.
Если есть какая-то теоретическая база, связывающая свойства сверхпроводимости со структурой и составом кристаллической решетки вещества, то можно было бы спроектировать и собрать нужный кристалл буквально по атомам. Возможно, за этим будущее — квантовые процессоры в каждом смартфоне и т.д.
Спасибо! Мне нравится буддизм, мудрое учение.
Помимо всего прочего, мне нравится еще и буддийская эстетика и архитектура. Это просто красиво. Серой и холодной российский осенью можно просто помедитировать вот на такие фотки и мысленно раствориться там, среди ярких красок древних буддийских храмов и солнечного света…
Архитектуру нужно открывать, систему команд, исходники компилятора под него. Лично мне это единственное что интересно — чисто эстетически, посмотреть как у них устроены команды, ведь это нечто непохожее ни на x86/x64, ни на ARM.
Я правильно понимаю, что это то же самое что делает одна единственная ассемблерная инструкция BSF (Bit Scan Forward)?
PS Вообще жалко что эти команды, как и битовые вращения, не вывели в операции языка C/C++ — они были бы более известны, как сдвиги например:) Для битовых сканирований можно было бы применить например унарные << и >>, для вращений бинарные <<< и >>>. Еще из полезных инструкций есть popcnt (количество единиц). А вот битового разворота (RBIT) в x86/x64 так и не завезли, к сожалению.
Давно интересовало — а почему fork? Откуда он взялся исторически, и почему такая странная (ИМХ) форма?
Кажется, гораздо более естественный способ реализации многопоточности — с помощью функции создания потока, которой в качестве аргумента передается указатель на функцию потока. pthread_create или что-то подобное.
Таблица виртуальных функций в общем и так понятна, но пример «на чистом Си» тоже пригодится — в любом случае понятнее чем на ассемблере. Кстати там лучше везде явно прописать какой-то calling convention — например _cdecl, а то в некоторых компиляторах convention у методов класса и у указателей на функции может не совпасть.
А вот таблица виртуальных таблиц (VTT), о которой данная статья, это действительно какая-то непростая штука.
Будет очень интересно!
Я пока еще не осознал всю мощь корутин, но вот замечание по поводу недостаточной низкоуровневости реализаци возникло из того, что разработчики стандарта выбрали конкретную модель реализации и уже завязали на нее некие классы стандартной библиотеки, а не предоставили универсальный языковой механизм вроде boost.context, с помощью которого (наверное?) можно было бы реализовывать любую модель.
Отличные статьи, спасибо! Правда про VTT кажется получилось немного скомканно.
А вообще, имеет ли виртуальное наследование отношение к виртуальным функциям (кроме того что используется общее ключевое слово и, судя по всему, схожие механизмы доступа)?
Интересно, но недостаточно низкоуровнево.
Можно ли было сделать поддержку всех вариантов (симметричные и асимметричные, стековые и бесстековые)?
Как это соотносится с корутинами из Boost?
Глупый вопрос: а как пользоваться Swift под Windows?
Еще вчера скачал дистрибутив, поставил… и что дальше?
При попытке собрать какое-то примитивное «hello world» из командной строки выдает какой-то мусор и ошибки.
←[1m<unknown>:0: ←[0m←[0;1;31merror: ←[0m←[1mcould not load the swift standard l
ibrary
←[0m
В режиме REPL (как интерпретируемые языки) тоже не работает.
Может есть какой-то плагин к Студии (это было бы идеальным вариантом)?
ИМХО все эти расширения gcc давно пора принять в стандарт. Они давно сделаны и давно и многократно проверены в реальном коде.
А компиляция одних исходников разными компиляторами очень полезна как раз для нахождения сложных ошибок. Сам все проекты под железо обязательно делаю максимально кроссплатформенными с одновременным написанием эмулятора под Windows. Отлаживать алгоритмическую часть очень удобно.
Вот когда подобным образом будет оцифрована не только математическая информация, но и информация из множества других областей знаний, тогда и наступит Сингулярность.
Помимо всего прочего, мне нравится еще и буддийская эстетика и архитектура. Это просто красиво. Серой и холодной российский осенью можно просто помедитировать вот на такие фотки и мысленно раствориться там, среди ярких красок древних буддийских храмов и солнечного света…
А какие планируются реселлеры?
PS Вообще жалко что эти команды, как и битовые вращения, не вывели в операции языка C/C++ — они были бы более известны, как сдвиги например:) Для битовых сканирований можно было бы применить например унарные << и >>, для вращений бинарные <<< и >>>. Еще из полезных инструкций есть popcnt (количество единиц). А вот битового разворота (RBIT) в x86/x64 так и не завезли, к сожалению.
Кажется, гораздо более естественный способ реализации многопоточности — с помощью функции создания потока, которой в качестве аргумента передается указатель на функцию потока. pthread_create или что-то подобное.
А вот таблица виртуальных таблиц (VTT), о которой данная статья, это действительно какая-то непростая штука.
Я пока еще не осознал всю мощь корутин, но вот замечание по поводу недостаточной низкоуровневости реализаци возникло из того, что разработчики стандарта выбрали конкретную модель реализации и уже завязали на нее некие классы стандартной библиотеки, а не предоставили универсальный языковой механизм вроде boost.context, с помощью которого (наверное?) можно было бы реализовывать любую модель.
А вообще, имеет ли виртуальное наследование отношение к виртуальным функциям (кроме того что используется общее ключевое слово и, судя по всему, схожие механизмы доступа)?
Можно ли было сделать поддержку всех вариантов (симметричные и асимметричные, стековые и бесстековые)?
Как это соотносится с корутинами из Boost?
Еще вчера скачал дистрибутив, поставил… и что дальше?
При попытке собрать какое-то примитивное «hello world» из командной строки выдает какой-то мусор и ошибки.
В режиме REPL (как интерпретируемые языки) тоже не работает.
Может есть какой-то плагин к Студии (это было бы идеальным вариантом)?
А компиляция одних исходников разными компиляторами очень полезна как раз для нахождения сложных ошибок. Сам все проекты под железо обязательно делаю максимально кроссплатформенными с одновременным написанием эмулятора под Windows. Отлаживать алгоритмическую часть очень удобно.