Board.KolibriOS.org

Posted: **Thu Mar 11, 2010 10:18 pm**

Неудобно как-то рассказывать, я всё таки пока тут больше как наблюдатель, но так получилось, что когда мы с моим научным руководителем выбирали тему для научной конференции проводимой моим вузом и он поинтересовался чем я сейчас занимаюсь, в числе прочего я упомянул Колибри и kcc о котором писал в соседней теме.
В общем...Тема моего доклада теперь звучит так:
"Технологии разработки программного обеспечения в Linux на С++ под ОС KolibriOS", если конкретнее, то на примере моего kcc. По ходу дела я разумеется буду рассказывать о самой колибри и мне интересно были ли какие-нибудь прецеденты её реального и полезного использования, хотя бы конкретно для своих нужд. Был бы очень благодарен если вы напишите. Конференция будет проходить 17 числа в МГТУ им.А.Н.Косыгина (Текстильном). Я студент Факультета Информационных Технологий , специальность САПР.
Вот составленный мной план, потом если кто-то заинтересуется могу выложить и презентацию.

Code: Select all

1. Обзор мини ОС, плюсы и минусы
  а) ReactOS - Размер 39 Mb, OpenSource версия WinNT 128-256mb RAM
  б) Damn Small Linux - Размер 50 Mb, 16 MB RAM , Базируется на Linux
  в) miniBSD - Размер 12-15 Mb, 32-256mb RAM , Базируется на FreeBSD
  г) KolibriOS - Размер 1.5 Mb, 8-16mb RAM, Уникальная система, потомок MenuetOS
2. Задачи и области применения
  а) Быстрая загрузка ОС для манипуляции файлами
  б) Восстановление базовой системы
  в) Демонстрационный стенд
  г) Система управления производством
3. Причины выбора KolibriOS, обзор ПО и инструментария
  а) Малые системные требования, встроенный полноценный графический интерфейс
  б) Поддерживает основные ФС: fat12\16\32 , ntfs, ext2\3
  в) Основной инструмент разработки в системе - fasm, а изучение ассемблера и было моей главной целью
4. Причины отказа от ASM , рассмотрение его + и -
  а) +На нём можно писать сверхкомпактные и сверхбыстрые программы
  б) +API ядра изначально ориентированно на fasm
  в) -Не удобен после современных языков
  г) -Нет столь удобных вещей как Структуры\Классы и прочие радости ООП
  д)-Привычка программировать на С\С++\Perl
5. Решение - написание kcc, Цели, База
  а) Цель: получить удобный , полнофункциональный кросс-компилятор Си для колибри
  б) Цель: Изучить asm AT&T и Intel синтаксисов, и API KolibriOS
  в) Цель: Изучить принципы работы компиляторов С\С++ и работы стандартной библиотеки Си
  г) База: Компилятор Си\C++ - GCC\G++ , Perl 5
  д) База: Debian Linux 5
6. Метод работы
  1) Написание программы на Си\С++
  2) Преобразование в AT&T ассемблерный листинг (g++ -S file.cpp -> file.s)
  3) kcc преобразует листинг AT&T в программу на ассемблере пригодную для колибри в Intel синтаксисе (kcc file.s -> file.asm)
  4) fasm преобразует асм программу для колибри в бинарный файл (fasm file.asm file -> file)
7. Примеры программ
8. Вопросы.

Posted: **Thu Mar 11, 2010 10:35 pm**

Alexus wrote:г) -Нет столь удобных вещей как Структуры\Классы и прочие радости ООП

Разве на fasm-е нет структур ? ООП действительно нет

Posted: **Thu Mar 11, 2010 11:06 pm**

viewtopic.php?f=7&t=897 - Колибри на производстве.

гадости ООП

Posted: **Fri Mar 12, 2010 1:07 am**

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

У меня колибри управляет сверхбыстрой цифровой камерой (500 кадров в секунду, каждый кадр с разрешением 1280х1024 пикселей, 10бит на пиксель) и проводит первичную обработку/анализ/запись видеоинформации в реальном времени.

Теперь по пунктам -

п.1:
как я понял, перечисляются только x86 мини-ОСи с графическим интерфейсом?
тогда обязательно добавь Haiku и DexOS.

п.2:
на "управление производством" система не годится. Хлопотно это.
И стрёмно.
Зато для управления отдельным техпроцессом, измерительным комплексом или научным экспериментом - то что надо.
И ещё - под минимальной ОСью очень здорово работают всякие ресурсоёмкие цифродробилки типа сеточных уравнений матфизики, Рунге-Кутты, Фурье, вэйвлеты и т.п. Ненавязчивый системный сервис не отвлекает процессор (и FPU!) от крутых вычислений. А если и отвлекает - то почти весь системный код уже лежит в кэше, системные вызовы как правило завершаются очень быстро.
Кстати, вот для таких задач твой ре-транслятор очень бы здорово пригодился. Библиотеки численных методов доступны на С и легко оптимизируются в коды FPU/3DNow!, причём libc практически не используется, разве что для вывода результатов, а <math.h> на почти 100% ассемблере с оптимизацией под 3DNow! можно скачать на сайте АМД.

п.3:
- открытый код!;
- простота и удобство системных вызовов,
- графический API не сравним по простоте ни с WinAPI, ни тем более с X11

п.4:
в) что значит "неудобен после современных языков"? неконкретно как-то звучит и субъективно. Лучше так: "портирование программ, написанных на ЯВУ для других систем, сопряжено со значительными трудностями"
г) - убери вообще. а то люди смеяться будут.

п.5:
а) "полнофункциональный" звучит несколько... претенциозно. "...с необходимой для эффективной работы функциональностью" было бы в самый раз.

Posted: **Fri Mar 12, 2010 1:50 pm**

2) Преобразование в AT&T ассемблерный листинг (g++ -S file.cpp -> file.s)
3) kcc преобразует листинг AT&T в программу на ассемблере пригодную для колибри в Intel синтаксисе (kcc file.s -> file.asm)

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

Posted: **Fri Mar 12, 2010 10:11 pm**

Serge
Я сейчас занимаюсь версией 0.03 , в ней реализована (уже) передача параметров в программу через argc, *argv[] , и конкретно сейчас я занимаюсь возможностью написания и подключения динамических библиотек, а статические файлы и так можно подключать через #include , но линковкой да нельзя пока, возможно и никогда этого не будет, но я работаю над kcc, и посмотрим чего достигну.

kogemyaka
Спасибо за ссылку, я её видел, на лоре помоему), а насчёт ООП, мне он нравиться, тк можно логику программы хорошо организовать, но на вкус и цвет))

art_zh
Спасибо, за примеры, очень благодарен.
п.1, максимальная длительность доклада 15-20 минут и то если удасться увлечь аудиторию, официально 8 минут (в прошлом году я сумел почти на пол часа растянул, занял 1ое место внутри вуза и 2ое на всеросийке)
п.2, очень хочется производство приплести, это должный эффект на аудиторию произведёт, может с натяжкой можно сказать?
п.3, да это всё я упомяну, апи мне тоже очень нравиться, главное чтобы все графические апи не испортились если будут вынесены из ядра, я если честно против вынесения графики за пределы ядра.
п.4, я подумаю над этим
п.5, моя цель именно создать полноценный заменитель компилятора с++ для колибри, и хотя это очень далёкая от осуществления мечта, врать и понижать уровень своих амбиций я не вижу смысла =)

Posted: **Fri Mar 12, 2010 10:33 pm**

4. Причины отказа от ASM , рассмотрение его + и -
а) +На нём можно писать сверхкомпактные и сверхбыстрые программы
б) +API ядра изначально ориентированно на fasm
в) -Не удобен после современных языков
г) -Нет столь удобных вещей как Структуры\Классы и прочие радости ООП
д)-Привычка программировать на С\С++\Perl

a) - чушь в заданном контексте; разумеется, сверхбыстрые программы можно писать на ассемблере, но их можно писать и на Си. Более того, с учётом уровня современных компиляторов код, написанный среднестатистическим программистом на асме, имеет все шансы проиграть по скорости коду, написанному среднестатистическим программистом на сях (ручная оптимизация, конечно, в принципе рулит, но это ж 1) знать много чего надо - в написании компиляторов таки участвуют знающие люди, 2) это должна быть именно оптимизация, которая вполне может поставить крест на читабельности - есть типовые оптимизации, которые вполне может произвести компилятор по нормальным сишным исходникам, но которые заметно усложняют ассемблерный код). Вот сравнение размера - таки да.
б) - частично чушь, регистры можно заполнять одинаково свободно из любого ассемблера, fasm тут ни при чём.
в г) про структуры уже высказались.

"Технологии разработки программного обеспечения в Linux на С++ под ОС KolibriOS", если конкретнее, то на примере моего kcc

А правда, что если тема сформулирована таким широким образом, то там будет ну хотя бы одна фраза в стиле "есть и другие, несколько менее извращённые средства использовать компилятор C и/или C++, работающий из другой ОС, в том числе и функциональная libc, но мне хотелось (тут пункты 5б и 5в), так что я буду рассказывать про kcc"? Я понимаю, что раз уж доклад про kcc, то о других подходах можно и не рассказывать, но хоть одна фраза? Как-то не хочется, помимо мифа "КолибриОС - система, написанная целиком на ассемблере" (да, это миф, причём уже довольно долгое время), создавать ещё один миф "на плюсах для Колибри писать можно, но для этого, помимо плюсов, нужен ещё и Perl, причём весь процесс занимает пару лишних шагов".

Posted: **Fri Mar 12, 2010 11:27 pm**

diamond
Разумеется я упомяну и все остальные подходы, тк не упомянуть их было бы нечестно, грубо и несправедливо по отношению к тем кто их разрабатывал и колибри. У меня важной частью ещё является слово "Linux", ведь я первоначально пытался из линя программировать по твоему мануалу =), с fasm получилось, а с gcc нет, вот я и стал искать иные пути)). А под Win, есть и С-- , и эмулятор колибри и тп, но я в винде раз в неделю самое частое сижу, чаще реже.

Posted: **Sat Mar 13, 2010 12:39 am**

Alexus wrote:п.2, очень хочется производство приплести, это должный эффект на аудиторию произведёт, может с натяжкой можно сказать?

Нет!!
Это будет рисовка ради дешёвых понтов. На тех, кто будет оценивать Ваш доклад, это только произведёт обратный эффект.
Серьёзный спец очень хорошо понимает, что ни один менеджер не пойдет на внедрение несертифицированной ОС для управления производством.
Более того, они также знают, что и программисту такое "внедрение" на фиг не надо. А что если послезавтра какому-нибудь идиоту с похмела оторвёт руку на конвейере? На кого все стрелки переведут?

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

Alexus wrote: п.5, моя цель именно создать полноценный заменитель компилятора с++ для колибри, и хотя это очень далёкая от осуществления мечта, врать и понижать уровень своих амбиций я не вижу смысла =)

Зачем же врать-то?
Просто надо ставить перед собой реальные цели...

Posted: **Sat Mar 13, 2010 12:43 am**

Alexus wrote:У меня важной частью ещё является слово "Linux", ведь я первоначально пытался из линя программировать по твоему мануалу =), с fasm получилось, а с gcc нет, вот я и стал искать иные пути))

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

Posted: **Sat Mar 13, 2010 1:01 am**

Чем разбираться в 8ми колёсном самокате, который при этом ещё и не катится , я лучше сделаю для себя более удобный и простой инструмент), а уж пригодиться ли он кому-то кроме меня не знаю, но на всякий случай буду это учитывать. Не зря ведь существует несколько путей к 1ой цели, я уважаю проделанную работу, но мне она не подходит, хотя бы по той причине, что по заявленной схеме она не работает. И метод её работы не достаточно очевиден и прост чтобы пытаться исправить её в несколько шагов. Для меня это значит, что оно того не стоит.

Posted: **Sat Mar 13, 2010 1:26 am**

Alexus
Забей на всех - делай как считаешь нужным!
Наш уважаемый (это не стеб!) Даймонд в свое время сказал:

diamond wrote:Мнение пишущего код программиста всегда приоритетнее остальных.

Posted: **Sat Mar 13, 2010 11:09 am**

Alexus wrote:Чем разбираться в 8ми колёсном самокате, который при этом ещё и не катится , я лучше сделаю для себя более удобный и простой инструмент

Просто как-то странно пытаться сделать ещё один велосипед, если не получилось снять с тормоза первый (причём с тем же рулём aka gcc).
В этом вообще слабость OpenSource - вместо того, чтобы разобраться и/или нажаловаться на недостатки существующего продукта, можно взять и создать новый. В результате, естественно, получаются уже два (а поскольку таких умных много, то иногда даже заметно больше двух) продукта с большими недостатками.

Posted: **Sat Mar 13, 2010 1:56 pm**

В этом есть определённые плюсы) и open source тут не причём, это в исходниках человека

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

Или если копнуть глубже)) в альтернативную историю по этой модели (забавная тема кстати) :
То в данный момент я бы вылезал на BBS сообщество обсуждающего принципы построения программ на бейсике, со своего любимого потомка altair 8800, через привычный модем и никогда не слышал о мышке =)))

Абсурдный мир) но зато какая приятная классика...

Posted: **Sun Mar 14, 2010 10:02 am**

а мне нравится, Дос всегда был моей любимой системой =)

Board.KolibriOS.org

Научная конференция

Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция

Re: Научная конференция