gcc я так понимаю под VLIW — нет?

VLIW VLIW'у рознь. Надо будет - шланг портируем, благо это недолго.

итого: нужно описание архитектуры VLIW эльбруса.

ISA, тегированной архитектуры, префетчинга для ускорения кеширования

gcc я так понимаю под VLIW — нет?

lcc — это не LCC-Win32 ?

Я ранее интересовался, и про gcc от МЦСТ упоминания не обраружил (это же подтверждает и КТ), но есть что-то свое - называется lcc - заменяет собой каким-то образом gcc. Не путать lcc (МЦСТ) c lcc-win32 (оффтотика) - ничего общего.

Но есть все основания предполагать, что есть в недрах МЦСТ и нормальный путь, без использования эмуляции и без лишних слоев.

Думаю, что есть заделы или может даже и результаты и по портированию (или хотя бы патчей) к gcc, превращающие последний в кросс-компилятор, дающий на выходе код vliw для Эльбруса.

одно другому не мешает. см. например, HLLVM — хаскель/простой ML поверх LLVM + метапрограммирование.

Про HLLVM ссылочку пожалуйста на страницу проекта и все что имеется полезного по теме HLLVM. Ушло мимо моего внимания :(

PS. Вот что-то удалось найти:

Haskell скрестили с LLVM

http://hackage.haskell.org/package/llvm

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

Не думаю, что этот путь возможен.

почему это?

Потому что он нафиг не нужен. Что он даст - возможность пустить несколько Linux x86? Ну и зачем это нужно МЦСТ?

L4Linux работает под L4

И?

под NOVA ещё проще

«Проще» или «работает»?

читаю книжку с описанием архитектуры:

4.4. Система динамической двоичной трансляции х86 → «Эльбрус» Неизменно актуальной проблемой при создании новых архитектурных платформ является перенос на них большого объема программного обе- спечения, разработанного для уже выпускаемых микропроцессоров, — не- обходимо либо портировать его, либо создавать заново, что, как правило, 198 Глава 4. Общее программное обеспечение нереально. Если же попытаться обеспечить совместимость создаваемой архитектуры с уже существующими, то ее возможности по части внедрения новых идей будут весьма ограниченными. Хорошо зарекомендовавшим себя способом решения проблемы является технология динамической двоичной трансляции, которая при наличии необходимой аппаратной поддержки была введена в состав ОПО «Эльбрус» [34]. Были реализованы два подхода к построению системы двоичной транс- ляции. При первом из них она работает между микропроцессором и за- пускаемыми на нем x86-кодами, транслируя коды BIOS, операционной системы, драйверов и прикладных программ. Вычислительный комплекс на базе микропроцессора «Эльбрус» с системой полной двоичной транс- ляции для пользователя неотличим от вычислительного комплекса на базе x86-микропроцессоров. При втором подходе эта система является обычным Linux-приложением и работает под управлением ОС Linux. Она позволяет запускать Linux-приложения для платформы x86, которые могут работать одновременно с приложениями в кодах платформы «Эльбрус». В состав двоичного транслятора включены интерпретатор и три транс- лятора, функционирующие на последовательных этапах оптимизации. Каждый из них запускается применительно к определенному участку кода, сформированному на предыдущем этапе, если число исполнений этого кода превысит заданный порог. Таким образом увеличивается эффективность результирующего кода. ---- Рис. 4.1. Результаты сравнения производительности системы динамической двоичной трансляции x86 → «Эльбрус» и микропроцессоров с архитектурой х86 (на уровне атома)

3 4. Воронов Н. В., Гимпельсон В. Д., Маслов М. В. и др. Система динамиче- ской двоичной трансляции х86 Эльбрус // Вопросы радиоэлектро- ники. Сер. ЭВТ. — 2012. — Вып. 3. — С. 89–108.

нашлось в книге от мцст описание архитектуры

ISA:

ПРИЛОЖЕНИЕ 3. Общая характеристика операций

префетчинг

ПРИЛОЖЕНИЕ 6. Выполнение аппаратурных операций откачки и подкачки содержимого регистров РгФ

микропроцессора «Эльбрус»

тегированная архитектура

4.5. Обеспечение защищенного исполнения программ на языках С и С++ 200 4.5.1. Семантические основы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 4.5.2. Контекстная защита . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 4.5.3. Реализация защищенного исполнения программ. . . . . . . . . . . . . . . . 201

3.1.4. Поддержка защищенного режима исполнения программ в аппаратуре. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

lcc — это не LCC-Win32, «Retargetable ANSI C compiler», а полностью своя разработка?? МЦСТ, подтвердите

судя по книжке, это далеко не тот самый lcc :)) тот lcc гораздо проще, а тут наворотили серьёзнее

очепятался. не HLLVM, а HLVM

вот Виталька Луговской делал свой MBase где есть лисп-0(схема) ядро поверх .NET, потом лисп-1 поверх лисп-0 и т.д. то есть, метациклический компилятор. у него там ещё через PEG можно свои DSL задавать, и IDE есть с раскраской (у меня она тогда нещадно тормозила, да и само MBase под другим дотнетом ексепшны сыпало, а на какую версию дотнета оно рассчитывалось — не ясно; ну да ладно, зато идея годная).

в HLVM та же самая идея, только поверх ML: реализован простой ML поверх LLVM; потом на этом ML пишется свой DSL, на нём следующий, и т. д. пока не получим в итоге хаскель или какой-то свой язык с произвольным синтаксисом и семантикой ML поверх LLVM.

под NOVA ещё проще

«Проще» или «работает»?

работает:

Speaking of base platforms, we are happy to have promoted the NOVA hypervisor to a first-class citizen among the base platforms. During the last months, this kernel underwent fundamental changes regarding its mode of development and its feature set. This prompted us to vastly improve Genode's support for this platform and leverage its unique features. If considering the use of Genode on x86-based hardware, NOVA has become a very attractive foundation. Section Embracing the NOVA Hypervisor describes the NOVA-specific changes.

http://genode.org/news/2012 :

NOVA Hypervisor supported on 64-bit x86 machines

NOVA is a so-called microhypervisor for the x86 architecture. It combines the principles of microkernels with capability-based security and hardware-assisted virtualization.

This ignited our renewed interest in promoting this platform to a first-level citizen of our framework. The first significant improvement is the recently added 64-bit support of NOVA. We enabled Genode to work with both variants of the kernel - 32 and 64 bit.

L4Linux работает под L4

И?

а то: паравиртуализованный линукс запускается под микроядром (гипервизором в случае NOVA).

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

а хочется запускать отдельные процессы, как VLIW и как x86 Linux.

Что он даст - возможность пустить несколько Linux x86? Ну и зачем это нужно МЦСТ?

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

но да, мы тут гадаем, а лучше пусть они сами объяснят, как эта штука работает.

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

Я ранее интересовался, и про gcc от МЦСТ упоминания не обраружил (это же подтверждает и КТ), но есть что-то свое - называется lcc - заменяет собой каким-то образом gcc

думаю, тут при сборке Gentoo или NixOS можно наступить на много граблей. начиная от отсутствия поддержки ключиков gcc, gcc-измов в libc, ядре, собираемом софте.

впрочем, собирали же Gentoo другими компиляторами, clang или icc. тут тоже придётся похожим образом, чтобы отделить компиляторопроблемы от дистропроблем.

судя по описанию в книжке, компилятор более навороченный — тут и IPO, и распараллеливание. интересно, фронтэнд у него хоть gcc-совместим (например, как open64 компилятор с китайского мипса, кстати, лол: там фронтенд от gcc и бекенд от sgicc, то есть: работающая межпроцедурная оптимизация и т.п.)

кстати, про NixOS. когда я туда последний раз заглядывал, там нельзя было задать так же просто, как в Gentoo USE-флаги: прописывались жёстко в рецептах. и рецепты для сборки под MacOSX,Linux,Cygwin были разные.

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

т.е. в NixOS бинарные патчи поначалу работать не будут. потом можно будет поднять гидру.

Думаю, что есть заделы или может даже и результаты и по портированию (или хотя бы патчей) к gcc, превращающие последний в кросс-компилятор, дающий на выходе код vliw для Эльбруса.

ну под какой-то VLIW gcc пытаются портировать, см. например pdf-ы выше по треду.

в природе существуют VLIW компиляторы на базе как GCC, так и LLVM.

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

При втором подходе эта система является обычным Linux-приложением и работает под управлением ОС Linux. Она позволяет запускать Linux-приложения для платформы x86, которые могут работать одновременно с приложениями в кодах платформы «Эльбрус».

иными словами, ядре VLIW линкус есть поддержка процессов только в архитектуре VLIW, а x86 линукс процесс статически транслируется в VLIW линукс процесс, который потом и запускается?

а я уж думал, тут что-то вроде 32bit/64bit multilib, и перекрытие ELF загрузчика, и прозрачная динамическая компиляция с кешированием оттранслированного, чтобы ядро умело запускать и x86 и VLIW процессы прозрачно для пользователя?

Что он даст - возможность пустить несколько Linux x86? Ну и зачем это нужно МЦСТ?

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

Паравиртуализация для отладки ядра на новой аппаратной платформе? Очень сомнительно.

в идеале, хотелось бы уметь из VLIW линукса запускать как VLIW линукс процессы так и статически оттранслированные x86 линукс процессы,

Да. Мой вопрос как раз об этом. Насколько я понимаю, Debian с multiarch это умеет через qemu - может, МЦСТ умеет это через свой бинарный транслятор.

Рис. 4.1. Результаты сравнения производительности системы динамической двоичной трансляции x86 → «Эльбрус» и микропроцессоров с архитектурой х86 (на уровне атома)

не очень впечатляет, скажем так. хотя это только начало.

чего не хватает: сравнения с неоттранслированным VLIW процессом на том же Эльбрусе, под родным компилятором. эльбруса эмулирующего x86 с родным эльбрусом.

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

на тех же самых тестах и бенчмарках.

кстати, про NixOS. когда я туда последний раз заглядывал, там нельзя было задать так же просто, как в Gentoo USE-флаги: прописывались жёстко в рецептах. и рецепты для сборки под MacOSX,Linux,Cygwin были разные.

Увы NixOS более гибкий чем Gentoo, но и требует более глубоких знаний. И работы по NixOS еще не початый край. Первым в списке у меня выкинуть главную фичу NixOS - аля dll-hell - protected storage NixOS.

т.е. в NixOS бинарные патчи поначалу работать не будут. потом можно будет поднять гидру.

Бинарные сборки и патчи не нужны мне даром, но для слабых машин и экономии времени гидру можно и нужно поднимать, или использовать гидру разработчиков, что и делает nix прежде чем собирать пакет, смотрит нет ли уже готовой сборки. Это поведение опциональное и можно ему сказать не использовать никаких двоичных сборок. Но собирается тогда не быстрее чем Gentoo.

вообще да, хотелось бы от МЦСТ более подробного описания, как они портировали линукс.

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

частично это есть в книжке, но как-то уж слишком общими фразами.

если они будут запускать открытые продажи и открывать документацию более подробно, тут сообществу будут нужны: версии всех компонент, патчи к baseline версиям, формат поставки (сорцы+патчи или бинарные блобы only).

чтобы например можно было сделать сборку других дистрибутивов, вроде Путещщ Gentoo и NixOS.

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

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

думаю, тут при сборке Gentoo или NixOS можно наступить на много граблей. начиная от отсутствия поддержки ключиков gcc, gcc-измов в libc, ядре, собираемом софте.

Не уверен, что мы получим возможность приобрести платы Эльбруса и документацию, но на ARM если не на v8 то хотя бы на слабеньких v7 точно попробую в этом году сборку Gentoo.

Кстати эту операцию уже успешно осуществили на такой слабенькой плате Odroid-X http://foss.org.ua/lib/thread.so.691

Увы NixOS более гибкий чем Gentoo, но и требует более глубоких знаний

рецепты более гибко задаются, и «репозитории» можно более гибко формировать.

что мне тогда ещё не понравилось: пакет bash при сборке зависел от переменной локали, LC_ALL. и поэтому или выдавал на не родной локали, или запускал пересборку всего.

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

и делает nix прежде чем собирать пакет, смотрит нет ли уже готовой сборки.

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

Но собирается тогда не быстрее чем Gentoo.

ну это как раз не проблема (??? или проблема: долгое время сборки на VLIW эльбрусе, мало памяти — вот тут и понадобится сборка кросскомпилятором с быстрого x86 в медленный VLIW эльбрус), главное лишь бы всё собиралось, невзирая на компиляторопроблемы

опечатался. не HLLVM, а HLVM

Всякая виртуализация у меня вызывает чувство осторожности и тревоги. Я бы сторонился любой виртуализации как чёрта.

, но на ARM если не на v8 то хотя бы на слабеньких v7 точно попробую в этом году сборку Gentoo.

попробуй. В смысле, сборку из под самой платы, не кросссборку?

собери весь мир с нуля.

потом сделай сборку кросскомпиляцией и прослезись.

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

(в идеальных условиях, x86 у тебя быстрее чем P-IV 2Ghz, сборка происходит в tmpfs, памяти много, гиг 8-16).

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

HLVM = high level virtual machine.

тут как и в LLVM нет виртуализации, а виртуальная машина есть. потому что например, в компиляторе и интерпретаторе языка уже есть виртуальная машина подмножества языка времени компиляции/времени выполнения. это «абстрактная машина» другими словами.

любая программа — это уже сама по себе виртуальная машина некоторого ISA, ABI, соглашений о вызове, интерфейса сисколлов, API непонятно чего в ядре. если ты соберёшь например Gentoo c eglibc вместо glibc, то потенциально ты уже можешь нарушить это API непонятно чего. вдруг там реализовано по другому и за недокументированные функции ядра дёргает. хотя нормальные люди так не делают, конечно.

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

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

Исходные коды ядра с правками под Odroid X доступны тут: https://github.com/hardkernel/linux Собирать можно как на самой борде, так и кросс-компилятором.

Только все очень долго :( и памяти (ОЗУ) мало.

Я подожду готовые платы с большим объемом ОЗУ (от 16Гб) или чипы пригодные для пайки дома - не BGA.

то есть, например LLVM биткод — воплощение абстрактная машина ассемблера. или программа на си — воплощение абстрактной си-машины. или, процесс линукс - воплощение абстрактной линукс машины.

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

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

платы с большим объемом ОЗУ (от 16Гб)

16 Гб ECC DDR-2 памяти? по чём обойдётся память и сама материнка в сборе?

IMHO, кроссборка быстрее будет.

например, как они на ECC памяти теги типов делали.

Благодарю, один секрет зачем МЦСТ потребовался рудимент в виде ECC теперь раскрыт.

Паравиртуализация для отладки ядра

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

*fixed

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

Ы? Это такая крутая паравиртуализация, которая дает прямой доступ к железу? Круто, но для переноса ядра не нужно - драйверы в пределах линии 2.6 переносятся без проблем (т.е. однажды отлаженные на 2.6.16 драйверы без проблем заработают и на 2.6.33).

судя по открытой информации, они реализовали контроллер памяти на ПЛИС. зашили в FPGA реализацию тегов типов на «лишних» ECC битах.

я так понимаю, сорцов прошивки не будет? :) ну хотя и не надо, пусть лучше ASIC контроллер сделают.

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

вот в Genode же запускают L4Linux поверх L4, или Linux поверх гипервизора NOVA:

тыц

The central theme of version 12.11 of the Genode OS Framework is self-hosting Genode on Genode. With self-hosting, we understand the execution of the entire Genode build system within the Genode environment. There are two motivations for pursing this line of work. First, it is a fundamental prerequisite for the Genode developers to move towards using Genode as a day-to-day OS. Of course, this prerequisite could be realized using one of the available virtualization solutions. For example, we could run L4Linux on top of Genode on the Fiasco.OC kernel and use the Genode build system from within an L4Linux instance. However, this defeats the primary incentive behind Genode to reduce system complexity. By having both Genode and L4Linux in the picture, we would indeed increase the overall complexity in configuring, maintaining, and using the system. Therefore, we would largely prefer to remove the complex Linux user land from the picture. The second motivation is to prove that the framework and underlying base platforms are suited and stable enough for real-world use. If the system is not able to handle a workload like the build system, there is little point in arguing about the added value of having a microkernel-based system over current commodity OSes such as GNU/Linux.

16 Гб ECC DDR-2 памяти? по чём обойдётся память и сама материнка в сборе?

Следующий степпинг (должен выйти в этом году) обещают с поддержкой DDR-3, а не DDR-2, и уже гигагерцовый.

вот в Genode же запускают L4Linux поверх L4, или Linux поверх гипервизора NOVA:

Они исследователи, им это интересно. А МЦСТ это зачем?

we could run L4Linux on top of Genode on the Fiasco

Замечательно... целая стопка экспериментальных технологий.

судя по открытой информации, они реализовали контроллер памяти на ПЛИС. зашили в FPGA реализацию тегов типов на «лишних» ECC битах.

Контроллер памяти там встроен в сам процессор, никаких ПЛИС.

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

:))

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

Да я и без полноценного дистра верю. Вопрос в том, что современные микроядра пригодны только для запуска целых операционных систем - это неинтересно, это умеют многие, от Xen и KVM до UML.

кроссборка быстрее будет

При равной частоте, количестве использованных ядер, скорости и объеме ОЗУ вряд ли кросс-сборка на x86 для ARM будет успевать за сборкой на самом ARM. Но увы - проверять пока не на чем, нет достойных плат на ARM для системника, на которые была бы озвучена хотя бы цена.

пусть памяти и больше понадобится, всё равно она дешевле чем ECC.

ECC память по затратам дороже обычной на 1/8 стоимости.

Не нужно брать дорогую брендовую ECC память, зачем оплачивать виллы и яхты паразитам ?

(т.е. однажды отлаженные на 2.6.16 драйверы без проблем заработают и на 2.6.33)

между 2.6.16 и 3.0 были помнится поломки в API которые влияли на драйвера.

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

а что ещё ты хотел запускать? что-то вроде экзоядра, чтобы в libOS был абстрактный API OS?

Genode куда-то к этому движутся. само Genode, как проект TRON: метастандарт, поверх которого идёт уже конкретная ось: Linux, L4, гипервизоры, ?экзоядра? (noux)

от Xen

а над Xen хаскель на «голом железе», без ОС запускали

При равной частоте, количестве использованных ядер, скорости и объеме ОЗУ

да-да, при прочих равных. Сейчас 8Gb планка стоит что-то около 1200 руб, 16 Gb (DDR3, не ECC) — 2400р., ECC сильно дороже.

сколько памяти ты можешь в плату на ARM вставить?

насчёт процессора — тоже сильно не уверен.

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

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

ну неECC брендовую я допустим понимаю — мегакрутые тайминги, которые дают +5% к производительности и +100% к ЧСВ. а вот брендовая/небрендовая, кроме повышенного тестирования (согласись, для сервера странно экономить на спичках) — не очень понятно, если тайминги те же.

между 2.6.16 и 3.0 были помнится поломки в API которые влияли на драйвера.

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

а над Xen хаскель на «голом железе», без ОС запускали

Что за железо ? Кто запускал ?

Они:

http://readwrite.com/2010/11/30/haskell-virtual-machine

http://corp.galois.com/technologies/ ?

Есть ли открытые проекты которые можно было бы воспроизвести дома ?