Хотя серьезно подходить к программированию все равно можно только на машкодах без макросов и процедур.
Ну, а серьезно -- хотя бы асм без макросов.
Хотя серьезно подходить к программированию все равно можно только на машкодах без макросов и процедур.
Ну, а серьезно -- хотя бы асм без макросов.
Помни. Только на компьютере можно семь раз 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
Имхо наоборот- макросы позволяют хоть как-то приблизить асм к уровню ЯВУ. Как говорится, на безрыбье...
И замедлить прогу
Изучая сейчас цэ после паскаля соглашусь, что он совсем не плох. Но никакие доводы не отберут пальму с кокосами у асма. Уж извините, можно и с ирландцем по-английски говорить, но как правило ирландский ему попонятней...
Помни. Только на компьютере можно семь раз 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[свернуть]
Все зависит от поставленной задачи, если надо костьми лечь но обеспечить быстродействие тогда тока "в машинных кодах сразу в шестнадцатеричном дампе" если задача за разумные сроки сделать приложение отвечающие по скорости и трудозатратам изначальным условиям почему бы не использовать отвечающие заданным критериям доступные инструменты : макросы, яву и т.д.?
Сколько проектов заморожено-развалилось из-за сложностей реализации в разрезе трудозатрат? Почему бы их не уменьшить (трудозатраты) если это можно сделать?
О сколько нам открытий чудных....
А как быть с доводами скорости и удобства разработки? Так что насчет "никаких доводов" будем считать что ты погорячился.
Не надо аналогий. Они никогда полностью не отражают обсуждаемую ситуацию.
Расскажи пожалста, каким это образом макросы могут замедлить прогу? Или злобный ассемблер при развороте макроса после каждой команды 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 когда меня режут, я терплю, но когда дополняют, становится нестерпимо.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
