AVR GCC&IAR

MP>> Hет - это похоже у тебя есть ускоритель! Ведь для поддержки MP>> проэкта на том-же языке далеко не всегда нужно разбиратся в MP>> тонкостях работы каждой подпрограммы, достаточно знать как это MP>> работает в общем и целом

AM> Да уж. Это смотря как код написан. Может автор принял решение, что AM> например, регистры R6 и R7 не подлежат модификации и используются для AM> хранения глобальных переменных. Ты об этом - не знаешь/не прочитал/не AM> увидел. При соправождении использовал R6 и получил букет трудно AM> объяснимых глюков.

MP> Я об этом знаю хотя-бы потому, что в HC11 (ежли не считать SP/PC) всего 4 MP> регистра, 2 аккумулятора A и B и 2 индексных X и Y.

Нет, ну ты за логикой то следи. "Я знаю, что в проекте на х51 регистры R6 и R7 ........ , потому что в HC11 всего 4 регистра."

MP> И заблудится в 4-х регистрах - это действительно надо уметь.

А в х51 4 банка по 8 регистров, а в AVR 32 регистра, а в MB90 32 банка регистров, каждый банк по 16 байт, который может мапиться как 16 8битных регистров, или 8 16 битых регистров или 4 32 битых регистров, или в любой из допустимых комбинанций.

MP> Для полных идиотов (которые умеют) есть команды psh/pul.

Они требуют стека, а он не бесплатен. 8 бесполезных push AR в х51 могут переполнить стек.

MP> В реальности использоание индексных регистров для привязки к какой-либо MP> точке озу видел только в Z80, и производном дибильных си-компиллеров на pc.

Очень даже не плохо эти индексные регистры используются для адресации параметров и локальных переменных функции в стеке. Например IAR C Z80 так может делать, как впрочем может делать и компилированный стек (задается опцией) И чем это так плохо, по твоему? И какие процессоры с индексными регистрами ты еще знаешь?

AM> Вот для этого не нужно переписывать, а нужно сразу писать на ЯВУ. AM> Противопоказаний к этому практически нет.

MP> Память, скорость.

Я и говорю - практически нет. Редко проект занимает ОЗУ под завязку, кроме того часто Си позволяет экономить ОЗУ, создавая компилированный стек для размещения локальных переменных функций, что очень сложно сделать руками на асме и приходится под каждую локальную переменную выделять собственный адрес в ОЗУ. ПЗУ - примерно тоже, даже с учетом оверхеда Си 15-30% верхний объем памяти кристалла в большинстве случаев не достигается, особенно с последней тенденцией удешевления flash и увеличения накристальной памяти в современных uC. Скорость - если успевает, но по барабану, если не успевает, критические куски переписываются вставками на асм. Остается твой единственный аргумент - внутреннее удовлетворение от бОльшей эффективности программы на асм. Только эта эффективность мифическая, не влияющая на показатели конечного устройства.

MP>> Я не буду этого делать, по нескольким причинам, вопервых это не на MP>> асме написано а на ваших любимых сях,

AM> Откомпилируй и полушишь exe, думаю тебе не проблема будет его AM> дизассемблирвоать. Ты же сказал, что тебе даже не важно наличие AM> исходного кода.

MP> Хитрый какой. То что я получу будет хуже чем творение олигофрена на асме.

Не важно, исходные условия задачи соблюдены.

MP> Опять-же все зависит от реализации. А реализация ppp есть например на асме MP> того-же pic-а... Хочешь на x51 перепишу? ;)

Тот кастрированный по самое нехочу ppp? Нет, не хочу. Я говорю про полноценный стек.

MP>> во вторых - я не знаю асм митцу и фуджи, в 3-х AM> То есть в конечно итоге - про 2 дня, и даже про неделю, это все AM> распальцовка. И ассемблер ты оказывается не знаешь нужный.

MP> Hе знаю.

Вот видишь, все новые и новые проблемы, свойственные твоему подходу.

AM> А кто вообще сказал, что ты его должен знать? Ты сказал про 2 дня те AM> уточняя необходимости знания ассемблера.

MP> Hу я же не обещал за 2 дня изучить ассемблер, следовательно подразумевается, MP> что я его знать должен.

Хорошо, переложи на х51.