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

http://kolibrios.org/

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

Чем?

Подходом и архитектурой

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

Думаю, достаточно бесполезный.

Порт линукса на какую-нибудь железяку - возможно полезное.
Опыт работы с БД - полезен.
Владение скриптовыми, веб-ориентированными языками - полезен.
Мастерское владение С++, Java, C# - ...догадайтесь сами.

А дрочево с ассемблером денег не принесет, это поза-поза вчерашний день!

Как минимум, надо писать на C. Если так интересны ОС - есть несколько embedded RTOS, которые можно поизучать, пописать к ним драйвера на специфичное оборудование.
Но это очень-очень узкоспециализированная область. Фирм в Нск мало, кому это нужно, зарплаты не намного выше, а даже и ниже. Опять же, никому не нужен программист,
который умеет писать только на асме. Знать надо ВСЕ. Кому нужен плотник, профессионально владеющий напильником, но не умеющий пилить ножовкой? Лучше нанять джамшута,
который может всего по-маленьку, но пашет много.

Ну я знаю pascal delphi yava писать на фасме стал не так давно и был сильно удивлен открывающимися возможностями.

Мда. Я надеялся на развернутый подробный ответ...


Полегче. У некоторых это -- сегодняшний день

У некоторых это будет даже завтрашним днём

У колибри подход: открытый код, пишут чтоб чемуто научится (век живи век учись ) ), структура взята из минуэта, она не лучше виндовской и её доработка особых плодов не принесёт.
Есть интересные разработки самого ядра, которые дают уникальные возможности по програмировании (програмировать легко, просто, возможности безграничны, что хочеш, то и воротиш). Разработка кстати реализуема только на асме (уже реализована), под неё свой менеджер памяти и система позиционнонезависимого кода.
В калибри к графики подход простой, я стартовал сразу с векторных шривтов, которые рисуются лучше чем в винде, прозрачные иконки и т.п. .

Как ни странно, но читается "минет".
Можете скриншотов наделать?

Скриншотов чего?

Своей системы, очевидно. Желательно не фотоаппаратом

Ну не минета же.

к сожалению тока так
Нажмите для просмотра прикрепленного файла

Ну, во-первых, шрифтом... таким гламурным и непонятным

Ну я нарисовал такой мохнатый шрифт для проверки работоспособности, даже его ещё не дорисовал. Других пока нету.
Качество сравните сами, моя отрисовка справо. Мне кажется она четче.
Нажмите для просмотра прикрепленного файла

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

Т.е. вы написали антиалиасинг шрифтов, причем не просто сглаживание, а субпиксельный рендеринг, превзошли Clear Type, и все это на Fasme? Ну прямо волшебная палочка какая-то этот фасм...

По поводу плотников - я не совсем правильно привел аналогию.
Представьте, что Вы - профессионал напильника. Можете выпилить им что угодно, сделать мельчайшие детали. Можете даже построить дом с помощью напильника (у вас правда уйдет на это 100 лет).
Но! На рынке труда есть тысячи простых рабочих из средней Азии, которые умеют пользоваться электрической дрелью, рубанком, циркулярной пилой, краном и экскаватором. Команда таких рабочих построит дом за 2 месяца.
Да, он не будет такой же идеальный как у Вас. Да, их прийдется нанять не 1, а несколько человек. Но работадателю выгода налицо!

Я вот, к примеру, могу в том же Qt в несколько строчек C++ кода вывести текст сглаженный, любого шрифта, поддерживающего Unicode, повернутого на 37.5 градусов в арабской ориентации справа на лево. И все это бесплатными инструментами, с прекрасной документацией и минимальными затратами времени. Кто больше интересен работодателю, я или вы?

Т.е. макрософт трудяга из средней азии,а я как вы там назвали, ну спасибо.
Мои шрифты не используют субпиксельное сглаживание, гораздо лучше. И поворачиваются на 360 гр.
Нажмите для просмотра прикрепленного файла

а запятая то где?

Ваш бы талант, да в нужное русло... И не падали бы Фобос-Грунты, и Google был бы новосибирской фирмой!

Запятая ещё не нарисована. Шрифты это не самая интересная тема там, гугл отдыхает

Я так понимаю у вы сделали какую то графическую систему, и в том числе растеризатор графических примитивов точки, (линии, полигоны),с антиалиазингом и пр? И все сделали на asm - е? Если так то круто конечно, но вопрос зачем, когда подобную штуку можно написать ну хотя бы на Си?
Есть не плохие реализации во FreeType, и AGG (правда последняя на С++).

Что то, можно и на С. А вы откуда знаете, что именно я сделал, алиасинга я не делал. После С и Паскаля попробовал fasm, уже как почти пол года, и возвращаться обратно не тянет. Кому, что нравиться. В fasme открылись возможности, которых в С нету

Какие например? Что можно сделать на asme лучше чем на С в том же рендеринге шрифта?

Ну я делал сглаживание, впринципи это тоже алиасинг. По скорости точно приемущество у фасма, компилирует голые команды процессора без добавления версии компилятора. Тот же цикл переводит в команды каким то своим способом, в принципи тоже работает, а такие команды как jmp в С и в других, более высокого уровня нету. Мне без неё никуда, и много чего еще

угу, в С команды jmp точно нет, а есть только тупое goto...

На fasme после любого сложения, add ax,2 точно знаеш что прцесор уже записал анализ результата во флаги и смело береш нужный j скачёк на любой код
если число 0, или меньне, больше в С эти возможности закрыты, которые дают безграничные возможности и нормальную скорость.

Я просто удивляюсь вашей работоспособности. Простоя я делал растеризатор 2D для embedded платформ, правда брал за основу (FreeType, AGG и пр), задача стояла получить максимальную производительность, пришлось находить узкие места в алгоритмах растеризации полигонов, линий (в частности генерации "капсов"), в алгоритме антиалиазинга, где то по возможности считать в целочисленных координатах, с той же субпиксельной точность повозиться, и пр, в общем ушло приличное количество времени.
А у вас я так понял именно эта часть не вызвала особых затруднений, и более того ее вы реализовали на ассемблере. И помимо этого вы сделали саму ОС, с загрузчиком, драйверами, ФС, и пр.

Сортировка пузырьком реализованная на fasm будет медленнее чем квиксорт реализованный на Си, и пр, это я к тому что в первую очередь гнаться за производительностью стоит на уровне проектирования и алгоритмов, но при этом в скорости разработки С/С++ выигрывает на порядки разработку на ассемблере, не говоря уже о дальнейшей поддержке и расширении.
Ну и сильно сомневаюсь что код на Си при грамотной реализации будет проигрывать реализации fasm, настолько существенно (если вообще будет), что стоит переходить исключительно на fasm.

Задачи разные, какието задачи решаются С компилятором лучше. Плохо реализованный алгоритм на асме проиграет С. Для создании оси лучше асм, в сети есть начатые оси на С.
Алгоритм закраски фигурки из линий безье второго порядка думал долго и на делфи. Получилось очень интересная реализация, после перевода на фасм получил повышение в производительности на много. Алгоритм придумываеш на листочке, потом переводиш в машинный код, не важно на каком компиляторе.
Файловую систему пишу только сейчас, т.к. драйвер для ide контроллера написал недавно. Интересуют драйвера для контролера achi диски eshi юсбиха вторая,
тема очень интересная подключеие больших устройств и в горяшем режиме

Я собственно не могу понять чем он лучше, у меня нет опыта написания ОС, но есть опыт написания драйверов для Linux. и просто работа с "голыми" ARM и DSP процессорами, и я бы не сказал, что Си чем то проигрывает ассемблеру. Тем более если вопрос касается драйверов, где большая часть работы с регистрами, прерываниями, DMA и пр.



А намного это насколько? Тем более что вы могли сравнить ассемблер, скомпилированный дельфовым компилятором, и ваш собственный. И я надеюсь, тесты были на одном и том же компьютере под одной операционной системой?

А в чем преимущество вашей ОС, кроме того что она написана на асме?
Она быстрее, реалтаймевее, универсальнее, законченнее? Чем ваш велосипед лучше других, которые по крайней мере работают?

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

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

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

взять открытые шрифты и сконвертить под свою ОС, не?

Не затрагивая тему ассемблера, операционных систем, шрифтов и прочего -- просто общее замечание.

Ребят, вам не кажется, что вы все, как и я, начинали изучение программирования со сложения двух чисел или там с решения квадратного уравнения?
Совершенно не имеет никакого смысла говорить человеку, что он изобретает велосипед и "займись лучше тем-то и тем-то", если ему интересно делать что-то конкретное, пусть он даже будет не первым, кто это сделает. Каким образом зарабатывать деньги, он потом и без советов разберётся

Человек пришёл, говорит: пишу то-то и то-то на том-то, хотите -- давайте вместе.
Ему стопицот ответов: да ну тебя, пиши лучше другое и на другом, а твоё никому не нужно.
Ну где конструктив-то, ёпрст.

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

Присоединяюсь к Fenster в том плане, что поддерживаю ваше желание что-то творить и учиться, однако, боюсь вы заблуждаетесь. Современные процессоры достаточно сложны и генерация кода для них в компиляторах - это большая наука, чтобы получить сравнимое качество кода на ассемблере надо очень много знать и понимать. Например, add ax,2 может вызывать partial register stall, inc eax - partial flag stall и это только самые простые вещи, а есть ещё cache, store-forwarding и т.д. и т.п. В идеальном случае ассемблер даёт лучшую производительность, чем C, но при простом и прямолинейном программировании на ассемблере зачастую это не так, и хороший C-компилятор при прямолинейном программировании на С даёт более быстрый код.

Не уверен, что такие тесты возможны и, боюсь, я не совсем точно выразился (пардон) - может быть и так и так - от алгоритма зависит. Примеры могу попробовать наковырять на досуге. Если не лень, можешь попробовать написать на ассемблере функцию типа, скажем, для AVX (Sandy bridge).

И мы сравним производительность ассемблера с кодом от компилятора.

Просто в работе приходтся довольно часто сравнивать код, написанный руками с кодом порождённым компилятором и зачастую второй лучше. Но, конечно, далеко не всегда. По роду службы мне больше всего прихдится иметь дело с программированием под SSE/AVX и там тонкостей побольше, чем в скалярных инструкциях, но и в скалярном коде выбор инструкций у компилятора бывает получше. Разница сильно скрадывается аппаратными оптимизациями и потому видна не часто, однако о том, например, чтобы избегать ложных зависимостей по регистрам, частичных зависимостей по регистрам и флагам и т.п. компилятор думает на автомате, а начинающий ассемблерный программист особо не задумывается. Я уж молчу про планирование инструкций (на больших out-of-order процессорах оно сейчас не актуально, но для мелких in-order ядер типа ARM/ATOM очень даже).

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

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

Вопрос в том сколько и каких деталей вы решите включить в ассемблер и что решит сделать компилятор. Всё не так просто, как кажется (почему - подумайте, ответ дам позже). Ну а про N вопрос вообще некорректный - функция утилитарная и должна хорошо работать при любых разумных N от 3х до 2^31.

Ремаркой про N я всего лишь сказал, что оптимизация для больших N отличается от оптимизации для малых. Я повторюсь: эта функция элементарна, и является плохим примером. Ассемблер (или интринсики) хороши там, где трудно донести до компилятора идею, что некоторое преобразование кода -- возможно. У меня есть примеры, когда компилятор генерирует скалярный код там, где векторизация была бы возможна, если бы можно было донести до компилятора ограничения на значения переменных.

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

На самом деле я не зря упомянул AVX: в смысле программирования на ассемблере векторного кода SSE4.2 был самым простым. Высокая пропускная способность памяти и невыровненные операции такие же быстрые как выровненные на выровненных данных + достаточная распространённость выравнивания на 16 байт давали близкую к максимальной производительность на простейшей реализации для этого цикла. С AVX всё сложнее: выравнивание данных на 32 байта распространено гораздо меньше, а с меньшим выравниванием операции на XMM работают лучше, чем на YMM. Банальный ассемблер - это 32-байт (YMM) невыровненные операции, он точно проиграет многовариантному коду от компилятора на невыровненных данных: компилятор как минимум породит отдельную версию для выровненых (на YMMах) и невыровненых (на XMMах) данных, как максимум - сделает векторизованный alignment peeling (с использованием инструкции maskmove) по a[] и породит две версии, описанные выше по b[]. Написать такое на ассемблере, безуслово, можно, но уже достаточно нетривиально.

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

Я не утверждал, что компилятор всегда лучше, я лишь утверждал, что он далеко не всегда хуже и что программирование на ассемблере для максимальной производительности требует глубоких знаний и размышлений. Что касается границ значений - иногда помогает поставить соответствующие условия if'ом или assert() с нужными границами. К сожалению мне не известен компилятор, где бы это работало всегда.

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

Совсем уже оффтопик, ну да ладно: для чуть более сложных функций (типа axpy, gemv) компилятор (icc) до недавнего времени не делал полную версионность, как мы, следовательно проигрывал. C 512-битными thoughput архитектурами все еще веселее

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

2Itch: мне даже за это платят

Работник(и) интела? Иного не могу себе представить...

Автору -- ссылку на github, до тех пор трололо.

Ну то есть вы - крутые программисты на asm'е и интринсиках и знаете все детали архитектуры и на столько неленивые, что можете написать 2-3-10 версий одного и того же кода для разных ситуаций. Собственно об этом и была речь: если всё знать и быть неленивым, чтобы всё заложить в код, то обогнать компилятор безусловно можно, вопрос только в полноте знаний и неленивости. Об этом и была речь.

Я кстати с этим и не спорил. Спорил только с удачностью примера.