х51 Опции

[Egel]

На каких МК стоит начать учиться, с каким языком работать и в какой среде сейчас осуществляется программирование(я знаю, что для х51 семейства программировали под DOS на TASM например )???
Еще очень интересно есть ли какие-то симмуляторы МК(не аппаратные) и как вообще лучше начать обучение в этой области?
Заранее огромное спасибо

[rv3dll(lex)]

ассемблер рулит

кейл генерирует сильно кривой код - так как не знает что от него хотят

[777777]

кейл генерирует сильно кривой код

Вы просто не умеете его готовить

так как не знает что от него хотят

Значит надо объяснить

[rv3dll(lex)]

Вы просто не умеете его готовить

Значит надо объяснить

ага очень удобно объяснить что при делении многобайтных чисел всё зависит от разрядности результата.---- проходили уже!!!!!

и примерные операции - не законченные это вообще песня

[777777]

ага очень удобно объяснить что при делении многобайтных чисел всё зависит от разрядности результата.---- проходили уже!!!!!

и примерные операции - не законченные это вообще песня

Ээ-э... А подробнее можно? А что такое "примерные операции"?

[rv3dll(lex)]

Ээ-э... А подробнее можно? А что такое "примерные операции"?

это когда точность расчёта зависит от оставшегося времени
по прерыванию например все данные уничтожаются - остаётся только результат

[zltigo]

по прерыванию например все данные уничтожаются - остаётся только результат

Честно говоря даже комментировать не хочется ахинею . Нет, я конечно понимаю, что через заднепроходное отверстие не прикладая ума можно получить любой "эффект", только вот зачем при этом пенять на компиляторы?

[rv3dll(lex)]

Честно говоря даже комментировать не хочется ахинею . Нет, я конечно понимаю, что через заднепроходное отверстие не прикладая ума можно получить любой "эффект", только вот зачем при этом пенять на компиляторы?

если не понимаешь не комментируй
для тебя умножение это

a <= b * c;

и это вне зависимости от того сколько разрядность чисел
если 2х байтные числа на 51 контроллере их за одну команду ассемблера не перемножишь
и займёт это десятки строк

бывают ситуации, когда неточный расчёт лучше, чем потеря данных

компиллятор ничего не знает поэтому на него надо пенять!!!! алгоритм его работы оптимален для большинства реализаций (он универсальный)

вот простой пример
чего бы не написал на си но при делении 32 разрядного числа на 32 разрядное на тексасе с помощью команды subd эта команда запустится 32 раза.

но елли результат не превышает 16 бит её жостаточно запустить 16 раз - ответ будет тот же самый.
проигрышь по производительности 2 раза

как компиллятору объяснить это?

[zltigo]

..если не понимаешь не комментируй

За десятилетия, так или иначе связанные с программированием на многих-многих ассеблерах, Fortran, Modula, С, .... Я понимаю очень многое

как компиллятору объяснить это?

Использовать явные преобразования типов, предварительное деление сдвигом для гробления точности, перед делением. Наконец, если критично, то и ASM функцию написать совсем не грех. Только вот кричать по незнанию/не владению инструментом о его непригодности явно глупо.

[rv3dll(lex)]

Использовать явные преобразования типов, предварительное деление сдвигом для гробления точности, перед делением. Наконец, если критично, то и ASM функцию написать совсем не грех. Только вот кричать по незнанию/не владению инструментом о его непригодности явно глупо.

преобразование типов чего и куда - число то 32 разрядное и дальше используется как 32 разрядное
там можно такого напреобразовывать

то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????

[zltigo]

то есть Вы УЖЕ согласились что в ответственных местах всёже компиллятор не обеспечивает экономичности ресурсов????

При умелом использовании от современных компиляторов получаем хорошо оптимизированный код.
Естествено, соревнование в ручной оптимизации, тем более на более чем старенькой 51 платформе, на уровне десятка-другого команд выграть у компилятора достаточно легко, хотя о сколь-нибудь впечатляющем выигрыше можно обычно говорить только на специально подобранных тестах
Глобально, при сколь-нибудь разумных затратах времении говорить об эффективности программирования на ASM уже не приходится. За последние годы, если не считать сопровождения одного безмерно древнего проекта на ASM размером под 200K кода, "ответсвенных мест" в которых я прибегал к использованию нескольких десятков строчек на ASM, пожалуй наберется штук 5-6.

Более того, где-то прошлой осенью пришлось столкнуться со старым изделием на 51. Разработчик тянул его много лет, вроде все работало, выпускалось, но как водится после его ухода полезли очередные проблемы Разбираться в 40K ASM кода совсем не хотелось, посему была просто портирована простенькая операционочка со 186 контроллера, поддержка однотипного железа, типовые протоколы и... уложившись в 30K получилося рабочий девайс не захлебываюшийся под нагрузкой, да и еще спокойно гонящий при этом в RS232 отладочную информацию. Честно говоря, предварительно морально был готов пару отработчиков прерываний на ASM писать, но не пришлось. Все стало работоспособным за счет более сложного построения системы а не тупого ускорения "ответственных мест".
По весне знакомый просил помочь с Тинькой - псевдонаучная поделка генерящая "волшебные" импульсы, впрочем к делу это отношения не имеет. Писали в ней софт вполне опытные ASM писатели, только вот результат получился странноватый - по верхней частоте/длительности чего-то не лотягивала до желаемого заказчиком, да и на анализаторе спектра что-то выглядило подозрительно очень - чего-то в алгоритме ошиблись явно. Переписывали сие уже много раз, писатели и заказчик находились в конфронтации.... Пришлось за несколько вечеров переписать на C. Тоже думал просто попробую (например на меге), а потом вылизывать придется - уж больно 2K флеша не впечатлили (отвык от малых форм ), да и по скорости достаточно сурово все по началу смотрелось. И ничего - 1.6K кода вместо 1.8K у ассемблерописателей при большем функционале и красотулечках (приблуда для продаже через TV Shop - важно) и двойной запас по девиации частоты вверх . И вообще ни одной сторочки (ну кроме штатного cstatrup) на ASM.

[SIA]

Великолепная иллюстрация того, что никакой "ручной код" не спасет от бездарности алгоритма. И наоборот, грамотная алгоритмика позволяет все сделать на нормальном языке.