Только один макрос В_SEL занимает 1% ПЗУ, а у меня 32 функции SEL, два преобразователя и R_TRIGER, всего 12%.
Вид для печати
Я извиняюсь, по-моему пользователь не должен этим заморачиваться, что у них откомпилировано, он должен понимать, чем проще придумает тем лучше(меньше ресурсов занимает), остальное проблемы Овена!
Иначе получается бег в мешке: побеждает не тот, кто быстрее бегает, а тот, кто быстрее бегает в мешке!
Даже если Овен подтвердит, что у них всё через одно место, через которое всё обычно в России делается и булевый мультиплексор занимает больше ресурсов чем целочисленный, от этого моё мировоззрение не может изменится и я не буду считать, что лучше применять целочисленный мультиплексор, там, где достаточно булевого. Вы сами не считаете, что это противоречит здравому смыслу?
Посмотрите вариант capzap'а:
Разумеется, понятнее и логичнее использовать int переменую и битовый сдвиг, а не велосипедить на 32 SEL'ах.
То, что 32 SEL'а занимают 12% памяти означает, что можно сделать линию задержки на 32*32==1024 бита и занимать она будет эти же самые 12-15% (+-)
С другой стороны, если бы в ОЛ были массивы, то составлять было бы проще.
Знаете что?
Бросаться словами все горазды.
Посмотрите на пример capzap'а. Тут вообще не нужны эти самые работы с отдельными битами. Нужно оперировать сразу пачкаими по 32 бита.
И, так получается, что именно это в ОЛ можно делать без особых извращений.
Да, с массивами было бы проще, но и так ничего. Поставили 2-4 блока и получили линию задержки на 32 бита. Какие ещё вопросы?
Первоначальный вопрос был в том, как сделать "из того что уже есть", а не "вот хорошо, если бы было", тогда было бы лучше.
Так что может помешать сдвигать биты внутри переменной, это даже очень прикольно!
Как-то так:
Вложение 28941
Задержка на 31 такт.