В предыдущем топике я обещал подробнее описать особенности программирования промышленных PLC, и почему такое программирование все больше напоминает разработку обычного софта. О языке IEC61131-3 ST (промышленном диалекте Паскаля) я уже писал, также хорошим вступлением можно считать вот этот хабратопик. Этот пост — о компиляторах PLC, средах разработки, особенностях программирования и эволюции языка и экосистемы. 
С выпуском GCC 4.8.0 разработчики набора компиляторов GNU Compiler Collection завершили переход на C++ в реализации GCC. Работа по переводу кодовой базы на C++ продолжалась c 2008 года, и теперь подошла к концу. Миграция на C++ означает, что теперь для сборки GCC из исходников обязательно требуется компилятор С++ 2003. 
Предыдущий мой пост был посвящен цикловым перестановочным оптимизациям, проблемам распознавания циклов, разрешению неоднозначности при работе с памятью, определению и важности зависимостей. Теперь я хочу сделать обзор одной из самых эффективных цикловых оптимизаций — автовекторизации. Хочется обсудить вопросы эффективности оптимизации, а также попытаться понять, какие факторы эту эффективность определяют. Всем, кому это интересно – добро пожаловать. При обсуждении я буду ориентироваться на интеловский автовекторизатор и автовекторизатор gcc 4.7.2. gcc я буду исследовать, чтобы подтвердить, что те принципы векторизации, которые я здесь пытаюсь сформулировать, имеют достаточно общую природу. Заодно мне, конечно, хочется понять уровень автовекторизации в gcc. Тут, конечно, есть некий элемент неравенства, поскольку я использую последний компилятор Интел, но не самую топовую версию gcc, но в основном я буду ориентироваться при сравнении на SSE инструкции. (Кстати, Intel активно участвует в разработке автовекторизатора gcc). Поскольку Intel и интеловский компилятор мне ближе, то ему я уделю кое-где больше внимания. Я не претендую на то, что я векторизаторный гуру и буду рад, если кто-то увидит мои ошибки и меня поправит. Букв будет много.
Времена, когда программисты пытались выжать максимум из размера своего приложения, безвозвратно ушли. Основной причиной является существенное увеличение объемов оперативной памяти и дискового пространства на современных компьютерах. Немногие помнят, как при загрузке приложения с кассеты можно было пойти покушать. Или как можно было считать моргания дисковода, косвенно определяя размер приложения. Пожалуй, только разработчики програмного обеспечения под встраиваемые системы до сих пор заботятся о размере кода и потребляемой памяти. Могут ли таблетки и смартфоны вернуть разработчиков «назад в будущее»?
Один мой друг, историк по профессии, подкинул мне замечательную идею об использовании древней мнемонической и счетной систем в современной криптографии. В процессе его рассказов об узелковой письменности Инков, я начал соображать, что все новое — хорошо забытое старое и было бы не плохо как-то применить древний опыт в современном мире. Первое, что пришло в голову — криптография. Это самое очевидное — просто сконвертировать узлы с ниток в байты и шифр готов. С одной стороны все казалось понятным, но потом я вспомнил про криптостойкость и другие параметры шифров и понял, что не обладаю достаточным опытом и знаниями в области криптографии, чтобы в одиночку разработать новый шифр. 
В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — Haskell и F#.
В F# меня соблазнило то, что его можно компилировать в MSIL сборки, что обеспечивает возможность использования библиотек классов F# в других языках Microsoft .Net, а также то, что он и сам может их использовать. Ко всему прочему, я ещё и начинающий разработчик Unity3D, и мне в голову пришла мысль: если компилируется в MSIL, то может можно использовать F# скрипты в Unity? Гугление дало ответ: по-человечески нельзя. Можно создать библиотеку классов, поставить в проекте ссылки на библиотеку UnityEngine.dll, компилировать и импортировать как ассет, после чего добавлять компоненты Mono-behaviour напрямую из библиотеки, но это не слишком удобно, согласитесь. Однако, пройдя гугл, Reflection и справку по Unity, мне все таки удалось приблизить(но не повторить в точности) работу с F# скриптами внутри редактора к тому виду, в котором производится работа со скриптами на встроенных языках. Подробности — под хабракатом.
template<class InputIterator, class OutputIterator>
OutputIterator copy(InputIterator first, InputIterator last, OutputIterator result) {
while(first != last) *result++ = *first++;
return result;
}