"Ночные" сборки KolibriOS

Share your distros and discuss others'
  • Хм... Какой-то флуд пошёл...

    В связи с упоминанием моей скромной персоны
    CleverMouse wrote:Albom - так и не определился
    хочу сказать, что русификацию делал не я.
    Shell 0.4.5 // 19.10.2010 // Pterox
    =======================================
    Программа теперь многоязыковая (английский, и русский язык). Программа полностью русифицированна.
    Для мне вообще это было не принципиально - главное, чтобы работало.

    p.s.
    Недавно заметил, что в shell есть один глюк (видимо, кроме меня этой программой не пользуется), но исправить времени не хватает. К тому же исходники не компилируются под linux... Надо править, править, править...
  • Albom wrote:Недавно заметил, что в shell есть один глюк (видимо, кроме меня этой программой не пользуется), но исправить времени не хватает. К тому же исходники не компилируются под linux... Надо править, править, править...
    Я заметил только, что в ночной сборке оно ругается на ".shell". Каюсь - дальше открытия и закрытия окна дело не дошло :oops:
  • Albom, раз непринципиально, значит, будут LANG_RUS и LANG_ENG. Я добавила в автосборку e80, после пересборки бинарник полегчал на несколько Кб.

    Если я сделаю наряду с выкладкой образа ещё выкладку файла с информацией об образе: сколько занято и свободно места в образе, сколько занято и свободно входов в корневой папке, сколько места занимают только файлы и только папки, это будет кому-нибудь интересно?
    Сделаем мир лучше!
  • CleverMouse
    Я думаю это будет полезная дополнительная информация, так что если тебе не сложно, то сделай.
  • Я добавила файлы .shell в автосборку.
    Я настроила создание файлов с информацией о сборке для каждой ревизии, они располагаются рядом с архивом образа и называются svn*-info.txt.
    Сделаем мир лучше!
  • Спасибо, за хорошую работу.
  • Mario wrote:Спасибо за хорошую работу.
    Присоединяюсь к Mario - просто нет слов благодарности!
    CleverMouse проделала огромную работу, и значительно облегчила жизнь всем. Нужно добавить новость в блоге 8)

    Вопрос: реально ли делать авто-сборку параллельно для 2 архитектур: i586 и i686?
    Я полагаю, что i386 (то есть, Pentium и ниже) практически не используется, и поэтому её можно не собирать автоматически.
    Тогда версия i586 будет подходить к тем процессорам, где есть только MMX (Pentium MMX, Vortex86MX, AMD Geode LX)
    А версия i686 - к более новым архитектурам (где есть SSE и выше).

    В каждой Ассемблерной программе, которая хочет использовать SSE или команды ассемблера i686, перед каждой такой командой добавляем блок:

    Code: Select all

    #if CPU_ARCH=i686
       <команды SSE / i686>
    #else
       <команды MMX / i586>
    #endif
    Соответственно, программы на ЯВУ компилируем с флагом i586 / i686. Какие будут комментарии?
  • KolibriOS requires at least a i586 compatible processor.
    The code i'm writing in NET branch has one or two conditional move isntructions, wich are introduced in i686 architecture.
    I believe its not needed at this point to create two binaries of the main kernel, I even think they will be identical!
    "Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." Albert Einstein
  • hidnplayr wrote:KolibriOS requires at least a i586 compatible processor.
    The code i'm writing in NET branch has one or two conditional move isntructions, wich are introduced in i686 architecture.
    I believe its not needed at this point to create two binaries of the main kernel, I even think they will be identical!
    Testing on eBox-3300MX, we have found a few applications written for i686, which do not work on Vortex86MX:
    1) Snake (game by dunkaist)
    2) Life2 (demo)
    3) infinity.obj (driver by Serge)
    4) fireworks (demo)
    5) View3ds (demo by macgub) - this one has 2 versions; now the i586 version is hard-code-compiled, so it works. But having two separate builds will allow to compile both versions, depending on architecture.

    Probably more - we are still testing. I think even infinity.obj alone is important enough to justify 2 versions (otherwise, there will be no sound on i586).
  • yogev_ezra
    Если я не ошибаюсь, то вся разница в сборке сводится к замене вызовов Int 0x40 на вызовы fast call. Отношения к MMX или SSE это не имеет. Соответствующая тема на форуме имеется.

    Проблемы с отсутствием нужных команд во всех больших ОС решаются обычно одним способом - замена оборудования. В большинстве случаев делать условную компиляцию под кучу разных процессоров это очень затратная работа. Если на компиляторах ЯВУ это решается опциями компилирования (но отнюдь не всегда), то в ассемблере это вообще проблема жесткая.
  • Mario wrote:yogev_ezra
    Если я не ошибаюсь, то вся разница в сборке сводится к замене вызовов Int 0x40 на вызовы fast call. Отношения к MMX или SSE это не имеет. Соответствующая тема на форуме имеется.

    Проблемы с отсутствием нужных команд во всех больших ОС решаются обычно одним способом - замена оборудования. В большинстве случаев делать условную компиляцию под кучу разных процессоров это очень затратная работа. Если на компиляторах ЯВУ это решается опциями компилирования (но отнюдь не всегда), то в ассемблере это вообще проблема жесткая.
    Я имел в виду только конкретные команды i686 ассемблера, например CMOV, и работу с регистрами SSE, например XMM0. В работе ядра пока никаких проблем.

    По поводу замены оборудования - смешно. Если я буду поставлять своим клиентам оборудование за 600$, то они найдут и деньги на операционную систему за 100$ (Windows), и полноценный Linux там будет работать нормально. А если мы имеем оборудование за 100-150$, и проект, для которого конечная цена очень важна (например, раздача компьютеров детям в Африке), либо низкое энергопотребление важно (например, сбор данных в пустыне и питание от солнечных батарей), или и то, и другое, но в то же время важна и скорость работы, и Колибри на нём просто "летает", а всё остальное тормозит, но в Колибри есть 3-4 программы, написанные под i686, то почему из-за этого нужно менять всё оборудование? Не проще ли тот блок, где используются функции i686/SSE, написать 2 раза?

    По большому счёту, из вышеперечисленного только драйвер infinity.obj является необходимым - без остальных 4 программ можно обойтись, но моё предложение - универсализация, то есть, для будущих программ тоже.
  • yogev_ezra
    Дело в том что америка уже открыта однажды.
    Мы с Serge поднимали этот вопрос в личной переписке, но поскольку на тот момент у нас не было в наличии оборудования с AC97, которое не имеет поддержки SSE, то вопрос был отброшен за ненадобностью. Никакой поддержки HDA тогда не было и в проекте. Однако я согласен что такие вещи как Infinity имеет смысл делать универсальными. Однако требовать этого от всех программистов бесполезно и бессмысленно.
    yogev_ezra wrote:По поводу замены оборудования - смешно. Если я буду поставлять своим клиентам оборудование за 600$, то они найдут и деньги на операционную систему за 100$ (Windows), и полноценный Linux там будет работать нормально. А если мы имеем оборудование за 100-150$, и проект, для которого конечная цена очень важна (например, раздача компьютеров детям в Африке), либо низкое энергопотребление важно (например, сбор данных в пустыне и питание от солнечных батарей), или и то, и другое, но в то же время важна и скорость работы, и Колибри на нём просто "летает", а всё остальное тормозит, но в Колибри есть 3-4 программы, написанные под i686, то почему из-за этого нужно менять всё оборудование? Не проще ли тот блок, где используются функции i686/SSE, написать 2 раза?
    Логика в твоем доводе есть, но мне приходилось слышать и читать противоположные мнения. Авторы которых считали смешным нанимать дорогостоящего программиста профессионала для написания более эффективного кода, когда например падение производительности решается тупой заменой оборудования. В общем у каждого свои резоны. Если есть человек желающий писать код это хорошо, но иногда приходиться более реалистично смотреть на вещи.
  • Mario wrote:Мы с Serge поднимали этот вопрос в личной переписке, но поскольку на тот момент у нас не было в наличии оборудования с AC97, которое не имеет поддержки SSE, то вопрос был отброшен за ненадобностью. Никакой поддержки HDA тогда не было и в проекте. Однако я согласен что такие вещи как Infinity имеет смысл делать универсальными. Однако требовать этого от всех программистов бесполезно и бессмысленно.
    Я и не требовал, это был только вопрос и тема к обсуждению. Моих знаний ассемблера хватит для Snake, но изменить Infinity - это уже выше моих способностей :oops:
    Mario wrote:Логика в твоем доводе есть, но мне приходилось слышать и читать противоположные мнения. Авторы которых считали смешным нанимать дорогостоящего программиста профессионала для написания более эффективного кода, когда например падение производительности решается тупой заменой оборудования. В общем у каждого свои резоны. Если есть человек желающий писать код это хорошо, но иногда приходиться более реалистично смотреть на вещи.
    http://www.laptop.org -> 200$
    Gecko Edubook + KolibriOS -> 150$ (в промышленных количествах)
    4 Edubook = 3 OLPC, в масштабах Африки это много
  • тогда может стоит обойтись без условной компиляции? Делать обнаружение SSE и CMOV через cpuid - и если не поддерживается - обходить оптимизированный код?
  • Who is online

    Users browsing this forum: No registered users and 10 guests