Pull to refresh
47
0
Send message
Весьма годно =)

Ну разве что в качестве придирки:
1) r3 и r5 никогда не будут больше 3 и 5 соотв., так зачем под них отдавать целых 2+ байт (в зависимости от компилятора). Аналогично с int flag
2) r3, r5, i, flag не могут быть отрицательными по определению, так зачем они signed?
3) читабельность %)
Деление — операция не шибко быстрая, особенно если используемый процессор не имеет блока аппаратного делителя. То бишь получается что сначала поделили на 15, посмотрели остаток, если не угадали, то поделили на 5, снова посмотрели остаток, а если опять не угадали, то делим ещё и на 3. В итоге до трёх делений на итерацию, что, как бы, многовато будет.
Парсер съел форматирование =\
Случайно использовал тег code вместо source.
Ещё раз:
void foobar(unsigned int n) {
	unsigned char is_mul_of_3;
	unsigned char is_mul_of_5;
	unsigned int i;
	
	for (i = 1; i <= n; i++) {
		is_mul_of_3=!(i%3);
		is_mul_of_5=!(i%5);
		if (!is_mul_of_3 && !is_mul_of_5) {
			printf("%d", i);
		}
		else {
			if (is_mul_of_3) printf("Foo");
			if (is_mul_of_5) printf("Bar");
		}
		putchar('\n');
	}
}
Я хоть и не программист, но всё же попробую ради интереса…
Вот функция на Си которая у меня получилась:
void foobar(unsigned int n) { unsigned char is_mul_of_3; unsigned char is_mul_of_5; unsigned int i; for (i = 1; i <= n; i++) { is_mul_of_3=!(i%3); is_mul_of_5=!(i%5); if (!is_mul_of_3 && !is_mul_of_5) { printf("%d", i); } else { if (is_mul_of_3) printf("Foo"); if (is_mul_of_5) printf("Bar"); } putchar('\n'); } }
Теперь собственно говоря почему так, а не иначе:
1) Первым проверяется вариант что число не является кратным ни 3, ни 5. Если посмотрите выборку от 1 до 1000, то получите таких чисел 533, против 467 случаев появления «Foo», «Bar» или «FooBar». Так что проерка на Foo и Bar будут проводиться только в том случае, если хотя бы одно из условий верно.
2) Флаги is_mul_of_3 и is_mul_of_5 вынесены по большей части только для красоты и читаемости, любой современный компилятор всё равно бы оптимизировал повторный вызов !(i % 3). И вообще, целый байт использовать на хранение одного флага не есть гуд, вдруг у нас какой-нибудь микроконтроллер =) Но пусть будет так.
3) Строки «Foo», «Bar» выводятся без символа переноса строки на конце, таким образом строку «FooBar» мы получим автоматически, когда число кратно 3 или 5. puthar в конце сделает нам перенос в любом случае.
4) printf тоже использовать для такой задачи не самая светлая мысль, здесь будет достаточно write. Но так смотрится «читабельнее» и привычне что-ли. Приходилось наблюдать как какой-то компилятор сам менял вызовы printf без параметров на вызов write.
5) Считать начинаем с единицы, а не с нуля, как многие здесь пытались, см. условие задачи.
6) Строки «Foo» и «Bar» должны выводиться _вместо_, а не вместе с числом, опять таки см. условие задачи.
> отсутствуют удобные графические оболочки для запуска и редактирования виртуальных машин
Если не секрет, а чем libvirtd + virt-manager не устроили?
Пробовал, конечно же, но почему-то не помогало, в причинах разбираться уже не стал.
XInput2 — штука хорошая. Правда для полного счастья нужно применять WM с поддержкой множественного фокуса, ибо в KWin это выглядит странно.

Я это использовал вот для чего:
Подключал к компу три клавиатуры и три мыши, спаривал клавиатуры и мыши в пары.
Написал для Wine патч в несколько строк, чтобы тот использовал пару клава+мышь, используя переменную окружения WINE_PTR_ID.
А далее дело техники — запускаем несколько копий Counter-Strike в Wine в оконном режиме, каждой копии передаём свой WINE_PTR_ID, с помощью KWin убираем рамки окон, с помощью wmctrl располагаем окна «мозаикой» на 42" телеке, и можно играть втроём на одной машине.
Ну это в теории, а на практике это было не особо юзабельно, ибо курсор «выпрыгивал» из окна, если резко дёрнуть мышью, и уползал к соседу. С этим я уже бороться не стал.
Не могу понять где здесь проблема…
Для ARM-архитектур никто обратную совместимость не отменял. Вас же не смущает что Debian собранный для armv4 спокойно работает на armv7 процессоре?
Как правило основная головная боль при запуске GNU/Linux дистров на новой ARM-борде — это портирование ядра, а приложения отдельных телодвижений уже не требуют.
В общем, основные пункты:
1. Ubuntu Phone (UP) будет ориентирована на запуск на ядре и драйверах Android, что позволит запустить UP практически на любом существующем Android-смартфоне при наличии root-а.
2. Очень большой упор делается на Web Apps с интеграцией с Ubuntu, а также HUD с активацией онлайн-поиска по различным контент-провайдерам (Amazon, Ebay и пр.).
3. Похоже, что в основе SDK будет лежать Qt+QML, в качестве IDE в ролике показали Qt Creator. Так что будет возможность разработки нативных приложений на C++ (для тех приложений, где скорость критична), а для более простых вещей предлагают использоват QML+JavaScript.
4. Опять таки большой упор Марк делал на идентиточности User Experience для всех типов устройств с Ubuntu (Ubuntu Phone, Ubuntu TV, Ubuntu Desktop).

Надеюсь что не будет как с десктопной версией Ubuntu, где слишком много чего сделано на Python, а иначе есть шанс, что UP будет работать даже медленней, чем Android.
Весьма оперативно.
Определенно лучше =)
Мне кажется, что название для топика не очень хорошее. Прочитав название, я уж было решил что теперь разработка остановится, пока они не получат свои деньги (фраза «просит деньги» может привести именно к этой мысли). А на самом деле тут всего-лишь объявлен сбор пожертвований, что для Open Source проекта дело вполне обыденное.
А вот классическое решение: kernelnewbies.org/FAQ/DoWhile0
Вообще на Kernelnewbies можно найти много полезных вещей.
Не нравится мне эта бумажка, ибо никаких технических деталей там нет.
Нет ни слова про набор регистров/команд/архитектуру и т.п. Сколько там, например, ступеней конвейера? Где можно пощупать эмулятор (это чуть ли не первое что делается при разработке новой архитектуры)?
Ребята из FSF технари до мозга костей, они бы не забыли упомянуть такие «мелкие» детали.
В случае ракет, скорей всего вы абсолютно правы. Но вояки чуть ли не основной потребитель:
1) встраиваемых процессоров и микроконтроллеров (например, пресловутый Комдив и Миландровский ARM);
2) DSP (ключевое слово для поиска Neuromatrix, это всего лишь один маленький пример из многих);
3) быстрых высокоразрядных ЦАП/АЦП с низкими уровнями дифференциальной и интегральной нелинейности (ибо без SDR сейчас никуда).
4) блоков статической памяти больших объёмов (динамическая вояками практически не используется);
Причём многое из этого они хотят в радиационно-стойком исполнении, так что это всё завязано на КНИ тех. процессы, применяются специальные правила разработки топологии (смотреть в сторону топологии транзисторов типа «dog bone»), специальные ячейки памяти состоящие не из 6 транзисторов, а из гораздо большего числа, специальные схемы триггеров с мажоритарной системой (по сути три триггера в одном). Для блоков памяти применяются специальные блоки фонового авто-восстановления данных с использованием кодов Хсяо/Хемминга, которые работают постоянно, если в данный момент нет обращения к памяти, дабы избежать накопления ошибок.

Вот вы знаете на чём строятся военные отечественные радиостанции? Смех смехом, а там Texas Instruments OMAP3 500 MHz с Linux на борту. И наши аппаратурщики постоянно пишут бумажки, с обоснованием невозможности использования отечественных компонентов, т.к. аналогов просто нет. А те параметры что они просят, на толстых процессах получить почти нереально.
Насколько мне известно, у Интеграла год назад был только 0.35 мкм, да и то PDK был в стадии активного пиления. Сейчас у Микрона есть 0,25 мкм КНИ в активной разработке, и вроде как есть коммерческий 0.18 мкм. У НИИСИ РАН есть КНИ-шный тех процесс 0.35 мкм. В прошлом году вообще был разыгран тендер (НИР) на разработку тех. процесса 65 нм =)
Могу предположить, что тупо «по линеечке», в случае наличия PDK (FDK) фабрики, на которой изготовлен оригинал микросхемы, потому что в КМОП схемах параметры транзисторов определяются двумя основными параметрами — длиной и шириной канала. Площадь стока и истока — вещь уже вторичная. Аналогично и для резисторов, зная его геометрические параметры, можно по формуле посчитать его сопротивление (формулу можно выдрать из правил PEX для Calibre/Assura или что они там используют).
Всё гораздо сложнее в случае отсутствия доступа к документации к тех. процессу, тогда начинаются всякие извращения с измериловкой, дабы получить параметры.
А как обстоят дела с «передиранием» тонких тех. процессов? Просто судя по тендерам, сейчас что-то толще 180нм вояк почти не интересует, за редким исключением, конечно.
Радиоэлектронное направление покрывается двумя федеральными целевыми программами — это гражданская ФЦП «Развитие электронной компонентной базы и радиоэлектроники» на 2008 — 2015 годы и «военная» (развитие ОПК) подпрограмма федеральной целевой программы № 1. Мне довелось просматривать выигранные тендеры за 2011 год по этим двум ФЦП (я даже распарсил резуьтаты и собрал кое-какую статистику). Могу сказать что в 2011 году по этим двум ФЦП было разыграно тендеров на общую сумму до 40 млрд. рублей. Что касается именно микроэлектроники — 75% заказов приходится на «военку», 25% — на гражданку. Естественно, что кто-то со стороны выиграть данные тендеры не может, нужно иметь очень хорошие связи.
Если вы можете сделать ручками схему гораздо лучше синтезатора, то я жму вам руку (виртуально, конечно).
Я пару раз пытался перехирить синтезатор, но понял что глупое это дело, потому что нужно учитывать слишком много факторов. Просто потом приходишь к пониманию того, что нужно написать, чтобы синтезатор выдал именно то, что тебе надо. И если правильно задать временные constraint'ы и вкрутить нужные оптимизации, то всё должно получиться весьма неплохо. Так что я больше склонен согласиться с мнением Fandir.
> где важно, использовать синхронизацию, где нет — отказаться от нее.
А это, я считаю, вообще весьма опасно, ибо с синхронизацией (особенно кросс-доменной), как праило, много головной боли. Просто человек есть человек, можно легко ошибиться.
За Gorthauer87 я, конечно, сказать не могу…
Но всё же не стоит недооценивать гибкость открытого софта.
Почему вы считаете, что переилить какую то систему под конкретную задачу это что-то из ряда вон выходящее?
Например, мне однажды пришлось слегка модифицировать SPI подсистему ядра для реализации нужной мне функции (Chip Select Decoding).
А однажды я за пару часов сделал грязный хак для Wine, чтобы можно было играть в некоторые игрушки в режиме разделения экрана (использовал XInput2, каждому окну Wine привязывалась своя пара клавиатура+мышь).
Не так давно я быстренько наваял плагин к Kate для построения дерева объектов в Verilog коде на базе уже существующего плагина.

Правда всё это были именно что грязные хаки, но сам факт, что если припрёт что-то подпилить под конкретную задачу — то в этом нет особой проблемы, если ты используешь Linux (точнее сказать, продукты с открытым исходным кодом). Так что зря минусуете человека.
Да откуда ж вы такие берётесь?
Я давний пользователь Linux (причём это единственная система на моём компьютере).
Помимо официально купленных нативных 4-х HIB и Oil Rush, у меня прицеплено около 20 игр к Steam-аккаунту, которые приходится запускать с помощью Wine (надеюсь, в скором времени появятся нативные версии).
По моему опыту, как раз таки пользователи Linux вполне платёжоспособны, ибо они, как правило, работают в высокотехнологичных областях, так что могут себе позволить покупать софт.
Например, один мой знакомый линуксоид занимается embedded-разработками, другой вообще занимается военными заказами.
Как вы не можете понять, что мы используем Linux не потому, что он бесплатный, а по совершенно иным причинам?

Information

Rating
Does not participate
Registered
Activity