И замедлить прогу
Изучая сейчас цэ после паскаля соглашусь, что он совсем не плох. Но никакие доводы не отберут пальму с кокосами у асма. Уж извините, можно и с ирландцем по-английски говорить, но как правило ирландский ему попонятней...
И замедлить прогу
Изучая сейчас цэ после паскаля соглашусь, что он совсем не плох. Но никакие доводы не отберут пальму с кокосами у асма. Уж извините, можно и с ирландцем по-английски говорить, но как правило ирландский ему попонятней...
Помни. Только на компьютере можно семь раз Cut, а один - Format. В реале все иначе. (c)
Власть людей сильнее, чем люди у власти.
Чем меньше мы смотрим на мир, тем больше задумываемся о нем. (c)
Скрытый текст
Can you help Robin in his quest for the silver arrow? (c) Odin "Robin of the Wood"
Мы все немного режем по дереву, а потом собираем корабли в бутылках.
Is it the same old story you are going to tell me
or is it the old story telling me and you we are the same?
http://www.sky.od.ua/~ptsk[свернуть]
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Все зависит от поставленной задачи, если надо костьми лечь но обеспечить быстродействие тогда тока "в машинных кодах сразу в шестнадцатеричном дампе" если задача за разумные сроки сделать приложение отвечающие по скорости и трудозатратам изначальным условиям почему бы не использовать отвечающие заданным критериям доступные инструменты : макросы, яву и т.д.?
Сколько проектов заморожено-развалилось из-за сложностей реализации в разрезе трудозатрат? Почему бы их не уменьшить (трудозатраты) если это можно сделать?
О сколько нам открытий чудных....Сообщение от TomCaT
А как быть с доводами скорости и удобства разработки? Так что насчет "никаких доводов" будем считать что ты погорячился.
Не надо аналогий. Они никогда полностью не отражают обсуждаемую ситуацию.
Расскажи пожалста, каким это образом макросы могут замедлить прогу? Или злобный ассемблер при развороте макроса после каждой команды halt вставляет?
Я тоже когда-то бегал и махал флагом "асм рулит, С для ленивых". Но после того как пришлось сначала разбираться, а потом переделывать чужую программу на асме (микроконтроллер 8051, довольно примитивно), я слегка поменял свое мнение. Плюс к тому, С обеспечивает кроссплатформенность- пара моих библиотек без проблем была опробована на трех разных процессорах (8051, TMS430, TMS470). Сколько бы я писал их вручную?
Так что для промышленного программирования лучше С пока ничего не придумали. И если очень уж требуется быстродействие, ассемблерные вставки никто не отменял.
(для справки- изучаю асм спека уже 7 лет, С/С++ уже 5 лет, плюс еще парочка асмов, полузабытый паскаль/делфи и т.д.)
ЗЫ. Все-таки на спеке не хватает С с приличной средой разработки...
На любом языке можно написать гадость, но на С не возможно написать оттактированую во времянках програму. Хотя можно пойти корявым способом и навесить всё на таймера, ну тогда програмирование будет ограниченным.
Наверное это что-то очень простое. Практически всё время нужно писать под процессор новые процедуры. Особенно если у тебя всего 128 байт памяти из которых для исполнения задачи нужно 128. Я хочу посмотреть как на СИ будет рашаться эта проблема ? Сколько я не видел фирмв с инициативами писать для МК на СИ, они постоянно занимаются поиском дорогих МК для решения серьёзных задач. Типичная гигантомания в стиле виндовсовских программ, года "весь пар уходит на гудок" ... =)
AAA когда меня режут, я терплю, но когда дополняют, становится нестерпимо.
Все зависит от дискретизации тактирования. Для периодов в миллисекунды и выше таймер как раз то самое средство. А если надо меньше- то тут, конечно, ассемблер.
Графическая библиотека для монохромных жк-дисплеев- всякие линии, точки, пропорциональная печать со стилями, работа с изображениями, буферизация, аппаратная независимость от реализации (работало даже на подключаемом через последовательный канал дисплее). Вторая библиотека- пользовательский интерфейс в стиле меню для бытовой техники, основан на графической библиотеке. Не бог весть что, но не ОЧЕНЬ простое.
А если у тебя куча устройств, множество источников прерывания, дофига разных таймеров. Я хочу посмотреть как на ассемблере будет решаться эта проблема, и, самое главное, сколько времени будет писаться эта программа.
Скажу по секрету, мощный буржуйский микропроцессор стоит дешевле наших слабеньких монстров (зато с 5 приемкой....), при этом ему не требуется большей части обвязки, да и по настройке и надержности он гораздо легче. А дорого-дешево- это все относительно, сэкономишь на процике- потеряешь на написании программы.
Бывает, соглашусь. Когда вместо PIC ставят навороченный процик "чтоб было"
у нас в фирме ставят из-за того, что у заказчиков софт под QNX...а наши делают для них железо, драйверы и тесты...на PIC же QNX пока вроде не портировано...хотя и pic PICу рознь...последние пики очень так навороченныеБывает, соглашусь. Когда вместо PIC ставят навороченный процик "чтоб было"
не, я не про такую ситуацию, а именно про "шоб было" %)
ага. а еще б я настоятельно посоветовал пописать на асме под АРМ
Практически каждый раз пишу под каждый LCD процедуры вывода, поскольку каждый LCD очень отличается от предыдущего. Практически везде использую поддержку окон, она, конечно, стандартная и написана только на assemblere. Последние попытки использовать предлагаемые библиотеки закончились тем, что вывод символов, конечно же разной ширины, выглядил как прин на "васике", хоте нет наш "васик" примерно в 10-ть раз быстрее. Короче скорость просто ужасная и подходит для отображения каких-нибудь крайне статических изображений. Мало того, я постоянно занимаюсь тем, что подрабатываю на фирмах где меня просят ускорить вывод информации на LCD'шки. Вот на следующей неделе еду делать работу для компании Квазар-Микро, которая выставляется на выставке на стендах. Их программисты не могут на 25 мипсовм "интеле51" сделать нормальную анимацию. Я же программирую только на асме, скорорсть разработки, конечно не лучшая, примерно неделя для любой задачи с переферией(а значит и LCD), а остальное это уже мелочи, которые долизываются по ходу дела. В последний раз делал прибор месяц тому назад с LCD 240х128 (epson), за день был написан полностью модул графики со всеми окошками, шрифтиками и другой мелочью. Поэтому не вижу смысла писать на Си, только тратить время на поиск, - "а почему же это всё так тормозит..." ...
AAA когда меня режут, я терплю, но когда дополняют, становится нестерпимо.
Немного оффтопа, но с рациональным зерном
Я для себя выбрал другой подход. Библиотека заточена под работу с дисплеями 128х64 (8 строк по 128 байт, пиксели вертикально). Но благодаря буферу позволяет работать с дисплеями с любой(!) организацией растра (успешно работал на многстраничном дисплее с "растровой" организацией). Естественно, тормознее (перекидывание буфера целиком на экран), но зато "все внутри".
Ну и библиотека пользовательского интерфейса. К ней в комплекте программа-конструктор и конвертер в С.
И путем каких манипуляций ты ее портируешь на другие процессоры? Переписывание?
Вышеупомянутый 8051 на 1мгц запечатывает весь экран (с прямой отрисовкой в дисплей) примерно за 0.4с. Это с пропорциональной печатью с обработкой (особенно трудно реализовывать наклонный шрифт в силу структуры).
Мдя
У меня в боекомплекте периферия- 6 счетных каналов (16-разрядные счетчики импульсов), жк-дисплей (символьный, с тупой организацией), лсд-матрица (примитив...), последовательный порт, плюс внутри математика. И все это на одном 8051 и на С. Прога писалась очень долго, ассемблерный вариант уже почти неуправляем (постоянные доделки-переделки), сейчас переписываю на С.
Второй вариант отличается графическим ЖК, 8 счетными каналами, 2 последовательными портами. Проц тот же самый, прога изначально писалась на С, благодаря чему доработка относительно проста.
А что тратить время? Надо включать логику!
Последний раз редактировалось Vitamin; 15.11.2006 в 00:43.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
