Я не то хотел сказать - я всю свою жизнь работаю только в той области, которая мне нравится: компьютеры. В этой области я пробовал себя в разных специальностях - программист, QA, hardware, system administrator, DBA, etc. И вот, за 15 лет работы, есть специальности, которые я освоил хорошо - например, QA, DBA, а есть такие, где ничего не смог, как бы не пытался (например, программирование). Но раз я уже открыл свою фирму 2 года назад, то начальником стал, а значит, уходить с панели после 40 мне уже не нужноMario wrote:Гым... как то после того как поработал: слесарем КИП и А, техником по обслуживанию оборудования, оператором видеоэфира ктв, верстальщиком газеты, изготовителем мелкой рекламы и последние 3 года программистом ассемблерщиком майнфрейма - в свои 31, я даже теперь затрудняюсь дать определение являюсь ли я проститутом (по твоему определению) или свободным человеком занимающимся тем что ему нравится (и подвернулось по случаю).
"Ночные" сборки KolibriOS
Хм... Какой-то флуд пошёл...
В связи с упоминанием моей скромной персоны
p.s.
Недавно заметил, что в shell есть один глюк (видимо, кроме меня этой программой не пользуется), но исправить времени не хватает. К тому же исходники не компилируются под linux... Надо править, править, править...
В связи с упоминанием моей скромной персоны
хочу сказать, что русификацию делал не я.CleverMouse wrote:Albom - так и не определился
Для мне вообще это было не принципиально - главное, чтобы работало.Shell 0.4.5 // 19.10.2010 // Pterox
=======================================
Программа теперь многоязыковая (английский, и русский язык). Программа полностью русифицированна.
p.s.
Недавно заметил, что в shell есть один глюк (видимо, кроме меня этой программой не пользуется), но исправить времени не хватает. К тому же исходники не компилируются под linux... Надо править, править, править...
Я заметил только, что в ночной сборке оно ругается на ".shell". Каюсь - дальше открытия и закрытия окна дело не дошлоAlbom wrote:Недавно заметил, что в shell есть один глюк (видимо, кроме меня этой программой не пользуется), но исправить времени не хватает. К тому же исходники не компилируются под linux... Надо править, править, править...
Albom, раз непринципиально, значит, будут LANG_RUS и LANG_ENG. Я добавила в автосборку e80, после пересборки бинарник полегчал на несколько Кб.
Если я сделаю наряду с выкладкой образа ещё выкладку файла с информацией об образе: сколько занято и свободно места в образе, сколько занято и свободно входов в корневой папке, сколько места занимают только файлы и только папки, это будет кому-нибудь интересно?
Если я сделаю наряду с выкладкой образа ещё выкладку файла с информацией об образе: сколько занято и свободно места в образе, сколько занято и свободно входов в корневой папке, сколько места занимают только файлы и только папки, это будет кому-нибудь интересно?
Сделаем мир лучше!
CleverMouse
Я думаю это будет полезная дополнительная информация, так что если тебе не сложно, то сделай.
Я думаю это будет полезная дополнительная информация, так что если тебе не сложно, то сделай.
Я добавила файлы .shell в автосборку.
Я настроила создание файлов с информацией о сборке для каждой ревизии, они располагаются рядом с архивом образа и называются svn*-info.txt.
Я настроила создание файлов с информацией о сборке для каждой ревизии, они располагаются рядом с архивом образа и называются svn*-info.txt.
Сделаем мир лучше!
Спасибо, за хорошую работу.
Присоединяюсь к Mario - просто нет слов благодарности!Mario wrote:Спасибо за хорошую работу.
CleverMouse проделала огромную работу, и значительно облегчила жизнь всем. Нужно добавить новость в блоге
Вопрос: реально ли делать авто-сборку параллельно для 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>
#endifKolibriOS 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!
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
Testing on eBox-3300MX, we have found a few applications written for i686, which do not work on Vortex86MX: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!
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 это не имеет. Соответствующая тема на форуме имеется.
Проблемы с отсутствием нужных команд во всех больших ОС решаются обычно одним способом - замена оборудования. В большинстве случаев делать условную компиляцию под кучу разных процессоров это очень затратная работа. Если на компиляторах ЯВУ это решается опциями компилирования (но отнюдь не всегда), то в ассемблере это вообще проблема жесткая.
Если я не ошибаюсь, то вся разница в сборке сводится к замене вызовов Int 0x40 на вызовы fast call. Отношения к MMX или SSE это не имеет. Соответствующая тема на форуме имеется.
Проблемы с отсутствием нужных команд во всех больших ОС решаются обычно одним способом - замена оборудования. В большинстве случаев делать условную компиляцию под кучу разных процессоров это очень затратная работа. Если на компиляторах ЯВУ это решается опциями компилирования (но отнюдь не всегда), то в ассемблере это вообще проблема жесткая.
Я имел в виду только конкретные команды i686 ассемблера, например CMOV, и работу с регистрами SSE, например XMM0. В работе ядра пока никаких проблем.Mario wrote:yogev_ezra
Если я не ошибаюсь, то вся разница в сборке сводится к замене вызовов Int 0x40 на вызовы fast call. Отношения к MMX или SSE это не имеет. Соответствующая тема на форуме имеется.
Проблемы с отсутствием нужных команд во всех больших ОС решаются обычно одним способом - замена оборудования. В большинстве случаев делать условную компиляцию под кучу разных процессоров это очень затратная работа. Если на компиляторах ЯВУ это решается опциями компилирования (но отнюдь не всегда), то в ассемблере это вообще проблема жесткая.
По поводу замены оборудования - смешно. Если я буду поставлять своим клиентам оборудование за 600$, то они найдут и деньги на операционную систему за 100$ (Windows), и полноценный Linux там будет работать нормально. А если мы имеем оборудование за 100-150$, и проект, для которого конечная цена очень важна (например, раздача компьютеров детям в Африке), либо низкое энергопотребление важно (например, сбор данных в пустыне и питание от солнечных батарей), или и то, и другое, но в то же время важна и скорость работы, и Колибри на нём просто "летает", а всё остальное тормозит, но в Колибри есть 3-4 программы, написанные под i686, то почему из-за этого нужно менять всё оборудование? Не проще ли тот блок, где используются функции i686/SSE, написать 2 раза?
По большому счёту, из вышеперечисленного только драйвер infinity.obj является необходимым - без остальных 4 программ можно обойтись, но моё предложение - универсализация, то есть, для будущих программ тоже.
yogev_ezra
Дело в том что америка уже открыта однажды.
Мы с Serge поднимали этот вопрос в личной переписке, но поскольку на тот момент у нас не было в наличии оборудования с AC97, которое не имеет поддержки SSE, то вопрос был отброшен за ненадобностью. Никакой поддержки HDA тогда не было и в проекте. Однако я согласен что такие вещи как Infinity имеет смысл делать универсальными. Однако требовать этого от всех программистов бесполезно и бессмысленно.
Дело в том что америка уже открыта однажды.
Мы с Serge поднимали этот вопрос в личной переписке, но поскольку на тот момент у нас не было в наличии оборудования с AC97, которое не имеет поддержки SSE, то вопрос был отброшен за ненадобностью. Никакой поддержки HDA тогда не было и в проекте. Однако я согласен что такие вещи как Infinity имеет смысл делать универсальными. Однако требовать этого от всех программистов бесполезно и бессмысленно.
Логика в твоем доводе есть, но мне приходилось слышать и читать противоположные мнения. Авторы которых считали смешным нанимать дорогостоящего программиста профессионала для написания более эффективного кода, когда например падение производительности решается тупой заменой оборудования. В общем у каждого свои резоны. Если есть человек желающий писать код это хорошо, но иногда приходиться более реалистично смотреть на вещи.yogev_ezra wrote:По поводу замены оборудования - смешно. Если я буду поставлять своим клиентам оборудование за 600$, то они найдут и деньги на операционную систему за 100$ (Windows), и полноценный Linux там будет работать нормально. А если мы имеем оборудование за 100-150$, и проект, для которого конечная цена очень важна (например, раздача компьютеров детям в Африке), либо низкое энергопотребление важно (например, сбор данных в пустыне и питание от солнечных батарей), или и то, и другое, но в то же время важна и скорость работы, и Колибри на нём просто "летает", а всё остальное тормозит, но в Колибри есть 3-4 программы, написанные под i686, то почему из-за этого нужно менять всё оборудование? Не проще ли тот блок, где используются функции i686/SSE, написать 2 раза?
Я и не требовал, это был только вопрос и тема к обсуждению. Моих знаний ассемблера хватит для Snake, но изменить Infinity - это уже выше моих способностейMario wrote:Мы с Serge поднимали этот вопрос в личной переписке, но поскольку на тот момент у нас не было в наличии оборудования с AC97, которое не имеет поддержки SSE, то вопрос был отброшен за ненадобностью. Никакой поддержки HDA тогда не было и в проекте. Однако я согласен что такие вещи как Infinity имеет смысл делать универсальными. Однако требовать этого от всех программистов бесполезно и бессмысленно.
http://www.laptop.org -> 200$Mario wrote:Логика в твоем доводе есть, но мне приходилось слышать и читать противоположные мнения. Авторы которых считали смешным нанимать дорогостоящего программиста профессионала для написания более эффективного кода, когда например падение производительности решается тупой заменой оборудования. В общем у каждого свои резоны. Если есть человек желающий писать код это хорошо, но иногда приходиться более реалистично смотреть на вещи.
Gecko Edubook + KolibriOS -> 150$ (в промышленных количествах)
4 Edubook = 3 OLPC, в масштабах Африки это много
тогда может стоит обойтись без условной компиляции? Делать обнаружение SSE и CMOV через cpuid - и если не поддерживается - обходить оптимизированный код?
Who is online
Users browsing this forum: No registered users and 10 guests