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. Скорость - если успевает, но по барабану, если не успевает, критические куски переписываются вставками на асм. Остается твой единственный аргумент - внутреннее удовлетворение от бОльшей эффективности программы на асм. Только эта эффективность мифическая, не влияющая на показатели конечного устройства.
A
Andy Mozzhevilov
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.
D
Dimmy Timchenko
Hi Oleksandr.
18 Jan 2004, 22:01, Oleksandr Redchuk writes to Dimmy Timchenko:
DT> ïÇÏ! çÄÅ ÔÁËÉÅ ÍÁËpÏÐpÏÃÅÓÓÏpÙ ÂÅpÕÔ? :)
OR> aspic
ó ÔÁËÉÍ ÁÓÓÅÍÂÌÅpÏÍ ÍÏÖÎÏ É Ó ÐÉËÏÍ pÁÂÏÔÁÔØ: ÎÁÐÉÓÁÔØ ÎÁ ÍÁËpÏÓÁÈ ÎÏpÍÁÌØÎÙÅ ÍÎÅÍÏÎÉËÉ, É ×ӣ. :)
Sun Jan 18 2004 23:25, Ilia Tarasov wrote to Alex Kouznetsov:
AK>> Hапример, конкретная проблема: какие слова должны входить в состав AK>> ядра? Вот и приходится по месту и под задачу перетряхивать ядро снова и AK>> снова... Hе знаю, может, у тебя таких сомнений не возникает, меня же AK>> при написании FVM они мучают постоянно: сделаешь маленькое ядро - AK>> потеряешь скорость, и наоборот.
IT> Можно делать кросс-компиляцию в два прохода. Hа первом определить IT> неиспользуемые слова, которые на втором проходе не будут скомпилированы. IT> Однако мне как-то не приходилось вносить такие уж серьезные изменения в IT> ядра.
Это как раз не проблема. У того же SwiftX это реализовано. Проблема в там, чтобы решить, какие слова реализованы в ядре, а какие - на их основе. И в том, чтобы решить, какой тип шитого кода выбрать. И еще в том, чтобы найти оптимальный баланс между безопасностью/скоростью (например, я проверяю стеки на переполнение/опустошение при каждой стековой операции, но в моей конкретной задаче скорость была неважна). Я уже перечислил три "оси координат", что дает множество вариантов, из которых надо выбрать оптимальный для задачи или класса задач.
Пока, Алексей
Join the Discussion
Have something to add? Share your thoughts — no account required.
Didn't find your answer?
Ask the community — no account required
Report Content
You are reporting this content to the moderators. They will look at it
ASAP.