C/C++, стандарти, компілятори, оптимізація...

Довелося недавно розповідати про представлення цілих знакових, зокрема -- від'ємних, чисел у C/C++ (signed int і сімейство). Так як часу було мало, і всі відомі мені архітектури (x86, AVR, ARM) використовують доповняльний код, (two's complement),  розповідав лише про нього. Зокрема, продемонстрував, що буде, якщо до максимального додатного значення, яке влазить у певний тип, додати 1, або від максимального за модулем від'ємного, відняти 1. (Див. додаток 1, або рисунок праворуч.)

#include <iostream>
#include <climits>

using namespace std;

int main()
{
 int m=-INT_MAX;
 cout << m << endl;
 --m;
 cout << m << endl;
 --m;
 cout << m << endl; 

 ++m;
 cout << m << endl;  

 }

Подивився на то мій колега, Орест Гера, і зауважив, що, здається, в стандарті такого не пише. Навів приклад, де компілятор відхиляється від цього правила.

Аналіз TIME.COM з PC-DOS 1.00

Написавши про DATE.COM, задумався, яка частина описаних "нюансів" коду була характерна для нього, а яка для коду Microsoft взагалі. Для контролю дизасемблював ще одну дуже схожу крихітну утиліту, яка теж не пережила виходу наступної версії: TIME.COM.

Загальні твердження та посилання в попередньому пості, "Аналіз DATE.COM з PC-DOS 1.00 ", тут -- тільки про TIME.COM, який теж є звичайною COM програмою.  Нагадаю хіба, що такі програми побайтово вантажаться у пам'ять, починаючи із зміщення 100h від початку сегменту (вище неї, в цих 0FFh байт, знаходиться PSP). Коли програмі передається керування, гарантується, що:

• CS=DS=ES=SS, всі вказують на той же сегмент,
• SP=0FFFEh -- стек у кінці сегмента, росте вниз,
• IP=0100h -- починаємо зразу після PSP.
• AL = 00h, якщо перший FCB в PSP має правильну літеру диску, 0FFh, якщо ні.
• AH -- аналогічно для другого FCB з PSP.

Код, сумісний з NASM:

Місяць - американці теж мацають

Програвши гонку за першу успішну посадку на інше небесне тіло, американці все ж змогли повторити це досягнення всього лиш через 4 місяці. І тут виявилося, що американський апарат незрівнянно досконаліший від "Луна-9". Ні, остання теж була доволі елегантною і творчою місією. Але дивіться самі.

Стосовно традиції починати із переліку невдалих запусків. Як не смішно, перша ж спроба виявилася вдалою. В це навіть самі автори не особливо вірили (офіційна оцінка ймовірності успіху -- 60%). "Surveyor-I, the spacecraft described here, was the first engineering test model to be flown" [Surveyor-I - A preliminary report - June 1 - 1966]. (Нагадую, "Луна-9" була 12-тим запуском в рамках програми м'якої посадки.)

Аналіз DATE.COM з PC-DOS 1.00

Колупався я недавно в антикваріаті ("MS/PC DOS 1.0", "MS/PC DOS 1.XX в емуляторах", "MS/PC DOS 1.XX "Ось ти який, північний олень!"", "DOS FCB"). Взагалі, цікаве заняття. :-) В процесі натрапив на людину, яка дизасемблювала та прокоментувала вихідні тексти IBMBIO.COM з PC DOS 1.00: "Reverse-Engineering DOS 1.0 – Part 2: IBMBIO.COM" (як і його бутлоадер: "Reverse-Engineering DOS 1.0 – Part 1: The Boot Sector"). Крім того, дизасемблювання  бутсекторів виявилося потужним засобом, щоб розібратися, чому в емуляторах не вантажаться різні версії ранніх DOS -- довелося і самому трішки спробувати.

Завершивши той цикл постів, на якийсь час заспокоїв свій археологічний свербіж. Виявилося -- не на довго. Повернення відбулося, коли, чистячи відкриті тематичні вклади, майже випадково натрапив на сайт якогось пана (пані?, але жінки, зазвичай, такими дурницями не страждають), що викладав образи своїх старих дискет: "Data Pack Rat". Дуже багато безцінного історичного матеріалу -- старовинні компілятори, оболонки, утиліти і т.д. Толком ще не розгрібав, натраплю на ще що цікаве -- розповім. Але знайомство почалося із майже чуда! У нього знайшлося кілька дискет, 1987-го року, на яких якийсь псих (в хорошому розумінні цього слова!) розповсюджував дизасембльований DOS 1.10 та DOS 2.10. Підписані вони так: 

Don Jindra

Information Modes

P.O. Drawer F.

Denton, Texas  76202

817-387-3339

Помилка в ARM CMSIS

(c) valessiobrito, "Open clipart"

Недавно я вже писав про труднощі, які зустрічаються на дорозі безбашенних програмерів, котрі насмілюються використовувати оптимізацію, програмуючи мікроконтролери (хоча, де ж вона може бути більш потрібною, ніж на цих малопотужних пристроях? ;-)

Ввімкнувши її у простому проектику для STM32 (в CoIDE),  теж зіткнувся з проблемами. Компілятор видав наступне:

       [cc] C:\Users\indrekis\AppData\Local\Temp\ccaX3kx8.s:1162: Error: registers may not be the same -- `strexb r0,r0,[r1]'
       [cc] C:\Users\indrekis\AppData\Local\Temp\ccaX3kx8.s:1187: Error: registers may not be the same -- `strexh r0,r0,[r1]'

CoIDE 1.7.1

З часу попередньої статті китайці випустили декілька оновлень свого славного CoIDE. Сказати, стала оболонка кращою чи гіршою, мені складно -- там такий мікс дрібних приємностей і дрібних косяків... :-) Але трішки по іншому стало точно. 

Спробую розповісти, як робота із CoIDE виглядає зараз. Версія, яку розглядав раніше -- 1.5.1, поточна -- 1.7.1. Багато відсилатимуся до попередньої статті -- щоб не повторюватися, хоча дрібні шматки просто цитуватиму. Розглядатимемо на прикладі плати STM32VLDiscovey. Тут, власне, сидить головне розчарування від останніх релізів. Ні підтримки STM32F3 (включаючи STM32F3Discovery), ні підтримки Stellaris (включаючи Stellaris Launchpad), поки так і не з'явилося. В принципі, принаймні STM32F3, можна пробувати додати самому -- див. діалог на форумі, "STM32F3Discovery - Demo Project for CoIDE", але я поки не пробував. Декілька слів буде і про прикручування C++.

[Update від листопаду 2015 року. Частина, присвячена С (Newlib) та С++ runtime містить багато неточностей та помилок. Існує більш детальний та точний варіант: "Стандартна бібліотека C та SemiHosting (на прикладі STM32 і CoIDE)" і "C++ із ARM GCC + STM32 (+ CoIDE)", відповідно. Крім того, див. пост про нову версію CoIDE, 2.0.3 beta: "CoIDE 2".]