> сам сделал DISC процессор
Вы имели ввиду RISC-V?
Сделали — HDL реализация на FPGA?
Если вы действительно разобрались, то открыты ли вы к вопросам? Как я писал в статье — порой квалифицировання консультация очень нужна.

Это 1-stage pipline. Для 5-stage pipline уже нужна реализация data hazards.
Это осмысленно только для задач производительности. Однако на FPGA особой производительности не достичь.
Более того — реализация на HDL действительно много. И параметрической генерации, оптимизации под конкретные платы и IP.
На данном этапе — для меня 5-stage pipline задача интересная, но избыточная.

Вы про то, что нет сигнала тактирования? Здесь тактированием выступает пошаговое выполнение инструкций. Разобраться через HDL на FPGA? Отладка — очень трудоемкая. Data hazards — это отдельная фундаментальная задача. Работа с кешем — тоже. Ну и доказательство корректности, к примеру для новых Extentions делать на Verilog? Я привел ссылки в статье на эту тему. Гляньте.

Вы еще пишете десктоп под POS и для винды? Или без Qt не видете жизни на марсе?27227
Тогда мы идем к вам. ))
Не ну правда — есть еще такие динозавры.
Однако когда у вас в пачке будет более 1k POS терминалов разных видов, и они будут требовать CI, причем по очень урезаному интернету типа EDGE, под NAT ко всему прочему. И POS не просто в разных городах но и в разных странах мира и разных end-point customers.
То тогда к вам быстро придет осознание что винду нужно выбросить в мусорку, а интерфейс писать под Web.
В результате — железяка которая с трудом ворочает Windows XP, без возможности поднять Windows 10 впринципе — легко и уютно живет под Linux, и достаточно легко поддается процессу CI/CD (continuous integration/Delivery). При этом сочетая в себе все возможности дизайна и функциональности под Web.

А можете развернуто ответить, в чем преимущество с hyperledger fabric?

Благодарен вам за такой труд.
Желаю много фана в этом процессе. ))

Ваш цикл — прекрасен!

Как вы думаете, насколько реально написать подобное для: ARM Cortex M4?

Небезызвестный Japaric не мало усилий прилагает, чтобы подобное было возможно, однако интересно — какой предел необходимых ресурсов, чтобы «завелось».

Статья хоть и простая, но интересная.
Я понимаю, что вы не программист. Но код оформлять нужно не скриншотами а оборачивать в тег .
И форматирование будет, и скопировать можно, чтобы воспроизвести. И вы не даете ссылку на код. Как-бы мувитон.
А именно на verilog файл, и на файлы настройки для linux. Действительно будет здорово, если вы весь код выложите на github.

Прошло уже 2.5 года, однако ваша статья заинтересовала. Статья не кажется для совсем новичков.
Можете подсказать список литературы, туториалов (язык не важен) — для достаточно быстрого освоение темы в достаточной мере, чтобы разобраться в вашем проекте и быть способным делать подобные эксперименты самостоятельно. Благодарю заранее.

Тут речь не совсем о разных клиентских приложениях, а о мультискиненге.
Причем у каждой из тем, при надобности может быть свой функционал прописанный в плагине.
Преимущество выше описанного метода в том, что он, как по мне, строго в логике Derby.jx 0.5.x с одной стороны (включая расположение вьюх, структуры расположения STYL и пр.), а с другой стороны использует сильные стороны Derby — расширяемость, в т.ч. за счет template components и UI-plugins.

А на добром слове — спасибо!!!

Если честно постоянно смущает фраза с официального сайта:

Derby works great with only a single app, though developers may wish to create separate apps if only certain sets of pages are likely to be used together. For example, a project might have a separate desktop web app and mobile web app. Or a project might have an internal administration panel app and a public content app.

Для меня важно, в частности, разъяснение причины такого утверждения и возможные негативные последствия. Наиболее логичной гипотезой является — возможные проблемы с Racer, при использовании каждой частью приложения разных БД.

Это таки не правда.
К примеру у меня под Ubuntu DOC категорически отказывается конвертировать в MOBI.

Я писал про deploy на Amazon EC2, а не масштабирование в инфраструктуре AWS. Тема именно так и звучит.
1. У вас есть какие-то сложность подключить Amazon Elastic Load Balancer, подключить Amazon Elasic Cache, настроить Amazon SNS, подключить Amazon CloudWatch, Натсроить AutoScaling, вынести css/js/images на Amazon S3+CloudFront?
2. У вас есть сложность настроить репозиторий git для обновлений версий на сервере?

Если с этим действительно есть сложности, я готов написать пост как это сделать, хотя это все и изложено в документации AWS.
По поводу Amazon Linux. Вы действительно считаете, что он ничем не отличается от Ubuntu 13.04?

Ну тогда уже лучше, пожалуй, на Erlang. ))

Компактно и всё по теме. Так держать!

Вот кстати хороший вопрос в тему…
Как грамотно в Derby структурировать код Избегая «спагетти» и соответствую SOLID?

Спасибо! Очень доступно изложено!

Как вариант, хотя и скупой: github.com/codeparty/derby-examples

Спасибо за линк.

Есть ли опыт «под нагрузкой»? Как себя ведет?
Какие бы вы рекомендации дали?
Что однозначно «стоит» делать, а что «не стоит»?