Области применения ПР110(примеры реализации)

[Василий Кашуба]

Это Ваши предположения или Вы проверили? Можно и Овена попросить функцию сварганить, чтобы 97% ресурсов не простаивало просто так(в данном случае)!

Только один макрос В_SEL занимает 1% ПЗУ, а у меня 32 функции SEL, два преобразователя и R_TRIGER, всего 12%.

[Сергей0308]

Только один макрос В_SEL занимает 1% ПЗУ, а у меня 32 функции SEL, два преобразователя и R_TRIGER, всего 12%.

Я извиняюсь, по-моему пользователь не должен этим заморачиваться, что у них откомпилировано, он должен понимать, чем проще придумает тем лучше(меньше ресурсов занимает), остальное проблемы Овена!
Иначе получается бег в мешке: побеждает не тот, кто быстрее бегает, а тот, кто быстрее бегает в мешке!

[Василий Кашуба]

Я извиняюсь, по-моему пользователь не должен этим заморачиваться, что у них откомпилировано, он должен понимать, чем проще придумает тем лучше(меньше ресурсов занимает)...

А чем мой вариант сложнее вашего? Не надо даже искать, или придумывать макрос В_SEL, а берёшь готовый из библиотеки и всё.

[Сергей0308]

А чем мой вариант сложнее вашего? Не надо даже искать, или придумывать макрос В_SEL, а берёшь готовый из библиотеки и всё.

Даже если Овен подтвердит, что у них всё через одно место, через которое всё обычно в России делается и булевый мультиплексор занимает больше ресурсов чем целочисленный, от этого моё мировоззрение не может изменится и я не буду считать, что лучше применять целочисленный мультиплексор, там, где достаточно булевого. Вы сами не считаете, что это противоречит здравому смыслу?

[Владимир Ситников]

А чем мой вариант сложнее вашего?

Посмотрите вариант capzap'а:

я тоже предложу вариант задержки, вдруг разберетесь как это работает

Разумеется, понятнее и логичнее использовать int переменую и битовый сдвиг, а не велосипедить на 32 SEL'ах.

То, что 32 SEL'а занимают 12% памяти означает, что можно сделать линию задержки на 32*32==1024 бита и занимать она будет эти же самые 12-15% (+-)

С другой стороны, если бы в ОЛ были массивы, то составлять было бы проще.

[Владимир Ситников]

Даже если Овен подтвердит, что у них всё через одно место, через которое всё обычно в России делается и булевый мультиплексор занимает больше ресурсов чем целочисленный, от этого моё мировоззрение не может изменится и я не буду считать, что лучше применять целочисленный мультиплексор, там, где достаточно булевого. Вы сами не считаете, что это противоречит здравому смыслу?

Знаете что?
Бросаться словами все горазды.

Посмотрите на пример capzap'а. Тут вообще не нужны эти самые работы с отдельными битами. Нужно оперировать сразу пачкаими по 32 бита.
И, так получается, что именно это в ОЛ можно делать без особых извращений.
Да, с массивами было бы проще, но и так ничего. Поставили 2-4 блока и получили линию задержки на 32 бита. Какие ещё вопросы?

[Сергей0308]

Посмотрите вариант capzap'а:


Разумеется, понятнее и логичнее использовать int переменую и битовый сдвиг, а не велосипедить на 32 SEL'ах.

То, что 32 SEL'а занимают 12% памяти означает, что можно сделать линию задержки на 32*32==1024 бита и занимать она будет эти же самые 12-15% (+-)

Здесь трудно не согласиться, так как это бы противоречило здравому смыслу. Хорошо придумали!!!

[Василий Кашуба]

Первоначальный вопрос был в том, как сделать "из того что уже есть", а не "вот хорошо, если бы было", тогда было бы лучше.

[Сергей0308]

Первоначальный вопрос был в том, как сделать "из того что уже есть", а не "вот хорошо, если бы было", тогда было бы лучше.

Так что может помешать сдвигать биты внутри переменной, это даже очень прикольно!
Как-то так:

Задержка на 31 такт.PNG

Задержка на 31 такт.

[Владимир Ситников]

Первоначальный вопрос был в том, как сделать "из того что уже есть", а не "вот хорошо, если бы было", тогда было бы лучше.

Разумеется. Но, если никогда не просить массивы, то их никогда и не сделают.
Поэтому я регулярно и напоминаю авторам ОЛ, что массивы нужны, что вот они, реальные задачи.