интерфейс — как смесь стилей из Ulead PhotoImpact и FD Painter.
А так лайтрум даже по сравнению с исходным фотоимпактом — много чего не умел (слои, произвольные выделения, контуры и прочая штука для ретуши/редактирования изображений). Как сейчас — не в курсе.
можно я отвечу? Если сравнивать с ведроидом — то 10ка очень удобная, шустрая и все такое.
Но как только сравним, например, с винфоном… то с удобством вопрос конечно открытый, но с «шустростью» все становится печальнее. 2гига оперативки + 2 ядра по 1 гигагерцу — это минимум для 10ки (перелопаченой QNX) от BB. Да, видео крутит паралельно с игрушкой, да, в случае чего «гасит» глючное приложение, причем без пояснения причины почему так получилось (обычно правда это порты из ведроида). Но иногда подвисает и сама операционка (редко редко, но такое случается, приходится ресетить аппарат и ждать пару минут пока он оживет).
А. ну еще с обновлениями (традиционно для BB) не все гладко, особенно если аппарат не взят в тридорога у местного оператора. Так что бубнами и акаунтами на тематических форумах стоит обзавестить заранее :). Сложного ничего нет, но типа «вынуть симку», или «вынуть батарейку» а потом подключать к компу для принудительной прошивки — частенько бывает необходимо.
погонял z10, постоянно использую BB PlayBook и BB 9100. гонял BB Storm — вот это был аппарат, кто бы в таком формфакторе выпустил на свежей операционке и элементной базе…
В итоге заказал за смешные деньги новый LG VS750. ВинМобайл + аппаратная клава за 50 баксов решили вопрос :)
Конечно, юзабилити телефонной части в мобайлах чуть менее чем убогая, зато все остальное — выше всяких похвал…
Эх… кто-бы Cyrix MII ( не путать с VIA Cyrix M2 — который суть тормозной Centaur) да + Tseng ET6000 в виде видеочасти реализовал бы на относительно современном процессе, Да с частоткой под гигагерц… это была бы бомба.
Самая удачная связка для встроенных систем. А конфигурируемость «цирикса» позволяла делать разные полезные фокусы. Чего стоило «фиксирование» в кэше диапазона памяти (без отражение изменений в оперативку) и доступ к кешу в один такт.… мячты мячты…
Мне кажется, мы путаем разные понятия — тестирование на соответствие требованиям и тестирование на отсутствие багов.
Для первого случая (когда проверяется соответствие требованиям) — наличие автоматизированных тестов, да еще и перед началом непосредственно программирования — это несомненный плюс и спорить тут не о чем вообще. Однако надеяться, что подобные тесты решат задачу нахождения багов — это обманывать себя.
Потому как в данном случае (при тестировании на наличие багов) просто необходимо учитывать фактическую реализацию. Посколько только так можно проверить как ведет себя код в случае получения данных, которые могут быть критическими именно для кода реализации, но не с точки зрения проектных требований. Код-ревью, в данном случае, используется как тест на бажность, точнее как его замена.
Что же касается методов разработки (с четкими требованиями/с нечеткими) то это в первую очередь проблема менеджмента. Если постановщик задачи не понимает предметной области, а со стороны «заказчика» людям все кажется «очевидным» или нет ресурса/интереса все объяснить — то другого варианта, кроме как все переделывать не по одному десятку раз — просто нет. Не все исполнители/разработчики к такому готовы морально и тут действительно, может понадобится менять команду. Или сменить того, кто общается с заказчиком :)
При соглашении о вызовах в формате cdecl такой проблемы как бы не существует. Конструкция языка Си… (три точки) позволяет объявлять функции с произвольным числом параметров. При cdecl стек подчищает вызывющий код.
Отлично, осталось только, чтобы вызываемая процедура знала, что ей туда подсовывают (если вдруг она «старой версии»).
Не факт. В случае 17 параметров, наверное, оптимальнее будет положить их в структуру и передавать указатель на неё. Причём, это будет справедливо как для языков высокого уровня, так и для ассемблера — Вы ведь сами утверждаете, что регистров не хватит. А в случае рекрурсии получится ещё и хорошая экономия — меньше работы со стеком.
Именно! Однако fastcall продразумевает только расширение в стек. Программист сам должен выбирать иные варианты передачи параметров.
Кстати, Ваша идея с первым параметром не так уж и нова.
Она (идея) и не может быть никаким нововведением — это лежит на поверхности. Но совершенно не понятно, почему не используется. Выгоды от такого подхода намного больше. чем от того, что применяется сейчас.
Нет, нельзя. Все эти языки так или иначе позволяют писать кроссплатформенные программы с высокой скоростью разработки и достаточным уровнем корректности.
VB, например, с кроссплатформенностью не сильно дружит. F# тоже не далеко ушел. Да даже С++ есть далеко не для всех архитектур и операционок. Тут спорить можно до хрипоты, но нам это ничего не даст.
Не понимаю вашего сарказма. Python и Java являются кроссплатформенными языками, и программы на них именно что портируемы.
Они не «портируемы», они «кроссплатформенны» в силу своей интерпретируемости (как бы это сейчас не называлось).
Хотя, на мой взгляд, здесь и C можно обойтись, потому что, скорее всего, под ту архитектуру, которая вам нужна, уже кто-нибудь написал соответствующую обёртку.
Отличное замечание. То есть мы сравниваем не языки, а наличие/отсутствие библиотек? Тут конечно, наличие библиотеки всегда лучше ее отсутствия. При этом, «почемуто», априори считается что программист на ассемблере не должен пользоваться сторонними библиотеками вообще, а Сшник — только и и обязан что их применять. В статье и говорится, что в силу неизвестных мне причин, библиотеки используют крайне спорные методы передачи параметров, которые, в дополнении ко всему, еще и не очень удобны при использовании асемблера.
Вы же против высокоуровневых языков, нет?
Почему если человеку нравится программировать на ассемблере, то это обзательно должен быть «красноглазый ретроград»? Я за любые языки программирования. Но это не повод плодить и оправдывать «корявые» решения что на С, что на ассемблере, что на любой другом языке.
Статическая или динамическая типизация — весьма холиварная тема. Лично я считаю, что статическая типизация есть благо, по разным причинам — начиная от обеспечения минимальной корректности программы и до упрощения создания мощных IDE. Однако типизация ни в коем случае не составляет сложности для пользователя программы.
К сожалению Вы наверно меня не поняли. Я всего лишь говорю, что преждевременная типизация, равно как и преждевременная оптимизация — это больше недостаток, чем преимущество. И дело не только в удобстве пользователя (как например, странность, почему в результате умножения переменной (с гарантированно вещественным значением) на целое значение «куда-то» пропадает дробная часть, это из SQL), но и в эффективности программы. Когда для вычисления A * B может быть использована и целочисленная (быстрая), так и вещественная (медленная) арифметика, в зависимости от фактических значений этих переменных на момент вычисления.
Пожалуйста, продемонстрируйте, как вы будете обрабатывать +7-909-78956234 и как число, и как строку. Желательно, на вашем любимом ассемблере.
А что тут демонстрировать? При преобразовании значения (например для поиска) — игнорируем все символы, кроме цифр. При этому исходное значение в строком виде не изменяем. В чем сложность то?
я бы добавил и «от возможностей линковщика». И это не смотря на то, что уже лет 20 как вещественная арифметика встроена в x86 серверные и десктопные процессоры
Два независимых стека у процессоров было давно и эту «фичу» активно использовал Форт.
Я предложил первый параметр использовать как маску значимых параметров. То есть, после увеличение количества передаваемых параметров старые модули/программы так и будут заполнять только известные им поля. О чем вызываемая подпрограмма может узнать из первого поля (битовой маски заполненых полей). А более новые программы смогут использовать «всю мощь» функционала обновленной подпрограммы.
А зачем каждый раз выделять память? Эта память может уже быть выделена заранее как на стороне вызывающей программы (передавать указатель на необходимое и уже выделенное место), так и на стороне вызываемого модуля (типа на каждый новый вызов берется следующий кусок из заранее выделенного объема для подпрограммы). Тут сложностей нет. Но при пакетной обработке (например алгоритмическая генерация интерфейса) предложенный подход может дать больший выигрышь в удобстве.
Да, Вы привели fastCall метод вызова. Он отлично работает, пока у вас не больше 10-12 параметров. После чего начинаются свистопляски, а где же хранить это значения, потому что регистры нам нужны для работы, а их (регистров) всего 16? Или вдруг понадобилось добавить 17й параметр? Здравствуй стек. Если бы регистров было 32 (как у Power) тогда да, достаточно сложно представить ситуацию, когда «с перепугу» понадобится параметра передавать 33 параметра. Но даже при увеличение количества параметров с 5 до 6ти приходится или менять все точки вызовов, или указывать, что это другая функция. Иначе как быть с «неконтролируемым» значением в 6м регистре, о котором на вызывающей стороне ничего не известно?
Ну почему, когда слышат «ассемблер» все сразу хватаются за «оптимизацию»? Это не самоцель при программировании на ассемблере. Эффективность складывается не только из «супер быстрого куска кода», но и из общей логики работы ПО, в режимах, удобных для системы. тут и меньший расход памяти неизвестно на что, и отсутствие излишней нагрузки на исполнительные устройства процессора (что экономит немного электричества). Да в конце концов — удовольствие от работы. Вам нравится писать на С, мне приятно писать на ассемблере. Я не вижу ничего в этом плохого. :)
а не подскажете, какой будет размер программы, которая делает всего три шага, приведенных ниже?
— получает 2 вещественных числа из консоли (вводит пользователь);
— перемножает их;
— выводит результат в консоль;
Никаких проверок, форматирования, использования инлайн ассемблера и прочего.
Вы можете объяснить, пожалуйста, зачем нужно программирование на ассемблере в современных десктопных или мобильных операционных системах?
Можно тот же самый вопрос задать про С++, VB, F#, Haskel. Да, С условно можно считать портируемым языком (хотя тот же Python, или Java «портируемы» еще как), пока дело не касается низкоуровнего программирования. Например нам понадобится что-то прочитать из порта ввода-вывода. Тут вся «портируемость» летит высоко и быстро. Или же Вы имеете ввиду, что просто вызов «библиотечной» функции решит проблемы? Так на чем писать эту самую библиотечную функцию? Если на С, то о какой портируемости идет речь, если переносите функционал с архитектуры, где фактически нет портов ввода выводы (они замаплены на адреса памяти) на архитектуру, где они есть?
Гораздо важнее скорость разработки, простота поддержки и портируемость приложений.
Ассемблер проигрывает в «портируемости» между архитектурами, но не между ОС. Что касается скорости разработки, так проигрышь получается по причинам, описанным выше — борьба со «специфическим» использованием архитектуры языками высокого уровня.
Также не очень понятен ваш скепсис в отношении компиляторов. Неужели вы считаете, что вы сами лучше будете знать, как именно и где лучше применить, скажем, какую-нибудь из инструкций расширения SSSE3?
Насчет SSSE. Там нет такого уж кошмара, вопрос лишь в подготовке данных. Сможете сами сделать — отлично, не сможете, нестрашно, есть, например, Фортран. А про «низкоуровневую модель памяти» я не понял. Что это?
Что значит — предусматривать все возможные виды «неправильных» входных данных? Вы имеете в виду валидацию, то есть, проверку содержимого, вроде того, представляет ли строка адрес электронной почты? Но это понятие не тождественно типизации. Более того, наоборот, типизация помогает валидации данных, потому что типизация ограничивает множество значений конкретной переменной. Валидация данных необходима в любом языке, независимо от системы типов.
Так типизация и решает задачу валидации данных. Чтобы быть уверенным, что вы умножаете вещественное число, а не строку. Но при этом, кроме удобства для компилятора, вносит дополнительные сложности как для программиста, так и для пользователя.
Как пример, у нас есть некий телефонный справочник. Номер телефон это что? Целое число или строка? При отсутствии типизации мы может обрабатывать его и как число (для поиска и сравнения так будет быстрее) и как строку — для хранения номера в том виде, в каком его ввел пользователь. Будь то +7-909-78956234 или же (909)78.956.2.34. Неважно, какой смысл в это вкладывал тот, кто его (номер) вводил в том или ином виде. В случае типизации мы вынуждены заранее ограничивать пользователя в формате вводимых данных, а потом еще и исправлять все это, если формат изменился, или же стали использоваться 2 разных формата для сотовых и стационарных телефонов.
проблема не в ассемблере, как таковом (кстати OS/390 вполне себе живет и здравствует в виде z/OS, причем до сих пор ассемблер там очень активно используется), а в том, что очень сложно найти рекомендации или подходы к проектированию ПО, с переложением на ассемблер. Особенность использования процессора со специализированными регистрами не рассматривается вообще. Модульность (особенности ее реализации, применительно к x86) упоминается для виду. Как будто знание мнемоник команд само по себе должно вдохнуть в программиста навыки «ведущего инженера».
Если система на ассемблере спроектирована и реализована грамотно, то ее поддерживать и развивать, как минимум, не сложнее, чем то же самое, реализованное на языках высокого уровня. А от «спагетти-кода» ни С, ни С++ не избавляют.
А так лайтрум даже по сравнению с исходным фотоимпактом — много чего не умел (слои, произвольные выделения, контуры и прочая штука для ретуши/редактирования изображений). Как сейчас — не в курсе.
Но как только сравним, например, с винфоном… то с удобством вопрос конечно открытый, но с «шустростью» все становится печальнее. 2гига оперативки + 2 ядра по 1 гигагерцу — это минимум для 10ки (перелопаченой QNX) от BB. Да, видео крутит паралельно с игрушкой, да, в случае чего «гасит» глючное приложение, причем без пояснения причины почему так получилось (обычно правда это порты из ведроида). Но иногда подвисает и сама операционка (редко редко, но такое случается, приходится ресетить аппарат и ждать пару минут пока он оживет).
А. ну еще с обновлениями (традиционно для BB) не все гладко, особенно если аппарат не взят в тридорога у местного оператора. Так что бубнами и акаунтами на тематических форумах стоит обзавестить заранее :). Сложного ничего нет, но типа «вынуть симку», или «вынуть батарейку» а потом подключать к компу для принудительной прошивки — частенько бывает необходимо.
В итоге заказал за смешные деньги новый LG VS750. ВинМобайл + аппаратная клава за 50 баксов решили вопрос :)
Конечно, юзабилити телефонной части в мобайлах чуть менее чем убогая, зато все остальное — выше всяких похвал…
Самая удачная связка для встроенных систем. А конфигурируемость «цирикса» позволяла делать разные полезные фокусы. Чего стоило «фиксирование» в кэше диапазона памяти (без отражение изменений в оперативку) и доступ к кешу в один такт.… мячты мячты…
Для первого случая (когда проверяется соответствие требованиям) — наличие автоматизированных тестов, да еще и перед началом непосредственно программирования — это несомненный плюс и спорить тут не о чем вообще. Однако надеяться, что подобные тесты решат задачу нахождения багов — это обманывать себя.
Потому как в данном случае (при тестировании на наличие багов) просто необходимо учитывать фактическую реализацию. Посколько только так можно проверить как ведет себя код в случае получения данных, которые могут быть критическими именно для кода реализации, но не с точки зрения проектных требований. Код-ревью, в данном случае, используется как тест на бажность, точнее как его замена.
Что же касается методов разработки (с четкими требованиями/с нечеткими) то это в первую очередь проблема менеджмента. Если постановщик задачи не понимает предметной области, а со стороны «заказчика» людям все кажется «очевидным» или нет ресурса/интереса все объяснить — то другого варианта, кроме как все переделывать не по одному десятку раз — просто нет. Не все исполнители/разработчики к такому готовы морально и тут действительно, может понадобится менять команду. Или сменить того, кто общается с заказчиком :)
Отлично, осталось только, чтобы вызываемая процедура знала, что ей туда подсовывают (если вдруг она «старой версии»).
Именно! Однако fastcall продразумевает только расширение в стек. Программист сам должен выбирать иные варианты передачи параметров.
Она (идея) и не может быть никаким нововведением — это лежит на поверхности. Но совершенно не понятно, почему не используется. Выгоды от такого подхода намного больше. чем от того, что применяется сейчас.
По остальным пунктам полностью согласен :)
Они не «портируемы», они «кроссплатформенны» в силу своей интерпретируемости (как бы это сейчас не называлось).
Отличное замечание. То есть мы сравниваем не языки, а наличие/отсутствие библиотек? Тут конечно, наличие библиотеки всегда лучше ее отсутствия. При этом, «почемуто», априори считается что программист на ассемблере не должен пользоваться сторонними библиотеками вообще, а Сшник — только и и обязан что их применять. В статье и говорится, что в силу неизвестных мне причин, библиотеки используют крайне спорные методы передачи параметров, которые, в дополнении ко всему, еще и не очень удобны при использовании асемблера.
Почему если человеку нравится программировать на ассемблере, то это обзательно должен быть «красноглазый ретроград»? Я за любые языки программирования. Но это не повод плодить и оправдывать «корявые» решения что на С, что на ассемблере, что на любой другом языке.
К сожалению Вы наверно меня не поняли. Я всего лишь говорю, что преждевременная типизация, равно как и преждевременная оптимизация — это больше недостаток, чем преимущество. И дело не только в удобстве пользователя (как например, странность, почему в результате умножения переменной (с гарантированно вещественным значением) на целое значение «куда-то» пропадает дробная часть, это из SQL), но и в эффективности программы. Когда для вычисления A * B может быть использована и целочисленная (быстрая), так и вещественная (медленная) арифметика, в зависимости от фактических значений этих переменных на момент вычисления.
А что тут демонстрировать? При преобразовании значения (например для поиска) — игнорируем все символы, кроме цифр. При этому исходное значение в строком виде не изменяем. В чем сложность то?
Ну вот, о чем и шла речь — обратите внимание на последнюю строку:
Я предложил первый параметр использовать как маску значимых параметров. То есть, после увеличение количества передаваемых параметров старые модули/программы так и будут заполнять только известные им поля. О чем вызываемая подпрограмма может узнать из первого поля (битовой маски заполненых полей). А более новые программы смогут использовать «всю мощь» функционала обновленной подпрограммы.
А зачем каждый раз выделять память? Эта память может уже быть выделена заранее как на стороне вызывающей программы (передавать указатель на необходимое и уже выделенное место), так и на стороне вызываемого модуля (типа на каждый новый вызов берется следующий кусок из заранее выделенного объема для подпрограммы). Тут сложностей нет. Но при пакетной обработке (например алгоритмическая генерация интерфейса) предложенный подход может дать больший выигрышь в удобстве.
Да, Вы привели fastCall метод вызова. Он отлично работает, пока у вас не больше 10-12 параметров. После чего начинаются свистопляски, а где же хранить это значения, потому что регистры нам нужны для работы, а их (регистров) всего 16? Или вдруг понадобилось добавить 17й параметр? Здравствуй стек. Если бы регистров было 32 (как у Power) тогда да, достаточно сложно представить ситуацию, когда «с перепугу» понадобится параметра передавать 33 параметра. Но даже при увеличение количества параметров с 5 до 6ти приходится или менять все точки вызовов, или указывать, что это другая функция. Иначе как быть с «неконтролируемым» значением в 6м регистре, о котором на вызывающей стороне ничего не известно?
Ну почему, когда слышат «ассемблер» все сразу хватаются за «оптимизацию»? Это не самоцель при программировании на ассемблере. Эффективность складывается не только из «супер быстрого куска кода», но и из общей логики работы ПО, в режимах, удобных для системы. тут и меньший расход памяти неизвестно на что, и отсутствие излишней нагрузки на исполнительные устройства процессора (что экономит немного электричества). Да в конце концов — удовольствие от работы. Вам нравится писать на С, мне приятно писать на ассемблере. Я не вижу ничего в этом плохого. :)
— получает 2 вещественных числа из консоли (вводит пользователь);
— перемножает их;
— выводит результат в консоль;
Никаких проверок, форматирования, использования инлайн ассемблера и прочего.
Ассемблер проигрывает в «портируемости» между архитектурами, но не между ОС. Что касается скорости разработки, так проигрышь получается по причинам, описанным выше — борьба со «специфическим» использованием архитектуры языками высокого уровня.
Насчет SSSE. Там нет такого уж кошмара, вопрос лишь в подготовке данных. Сможете сами сделать — отлично, не сможете, нестрашно, есть, например, Фортран. А про «низкоуровневую модель памяти» я не понял. Что это?
Так типизация и решает задачу валидации данных. Чтобы быть уверенным, что вы умножаете вещественное число, а не строку. Но при этом, кроме удобства для компилятора, вносит дополнительные сложности как для программиста, так и для пользователя.
Как пример, у нас есть некий телефонный справочник. Номер телефон это что? Целое число или строка? При отсутствии типизации мы может обрабатывать его и как число (для поиска и сравнения так будет быстрее) и как строку — для хранения номера в том виде, в каком его ввел пользователь. Будь то +7-909-78956234 или же (909)78.956.2.34. Неважно, какой смысл в это вкладывал тот, кто его (номер) вводил в том или ином виде. В случае типизации мы вынуждены заранее ограничивать пользователя в формате вводимых данных, а потом еще и исправлять все это, если формат изменился, или же стали использоваться 2 разных формата для сотовых и стационарных телефонов.
Если система на ассемблере спроектирована и реализована грамотно, то ее поддерживать и развивать, как минимум, не сложнее, чем то же самое, реализованное на языках высокого уровня. А от «спагетти-кода» ни С, ни С++ не избавляют.