Oberon space

Как вы думаете - какое?
max( Int32 ) ?
Я тоже так думал... Нет.
max( Int32 div 2 ) ?
И про это помышлялось... И - на этот раз - не то.

Оказывается, есть-ТАКИ НЕКОЕ МАГИЧЕСКОЕ ЧИСЛО!

0x3FFFFFF

Кто-то что-то знает по этому поводу? Читали ли где-то? В "этих ваших интернетах" находили, почему и отчего?

Предыстория
-----------------
Рисовался некий график некоей последовательности измерений некоего параметра.
Оператор (в смысле - хомо сапиенс) начал "увеличивать" график в "интересном" участке измерений...
В какой-то момент линия графика перестала перерисовываться. Не переполнение, ни что-то кракозябренное, НЕТ! Просто - соседние линии, уходящие "глубоко под низ" экрана, были видны, а линия, которая (по своей "виртуальной" длине) выходила за какое-то верхнее значение, НЕ перерисовывалась GDI...
Причём, там было "нормальное" значение y(игрек) координаты ( 0 <= y <= (max( Int32 ) - 1) ).
Собснагря, значение $3FFFFFF было "найдено" чисто делением пополам в "набросанном" примерчике на дельфе с двумя TEdit-контролами и TPicture.
Такое впечатление, что GDI оперирует неким универсальным "мировым пространством", в котором это значение - верхняя граница координаты мира.

Остался Сильно Уивлённым.
Сколько работал с виндовой графикой - первый раз на такое нарвался!

С Дельфи не работал с, приблизительно, 2002-2003 годов.

Сначала ушёл в С/С++ на QNX. Потом как-то постоянно в сях на встроенных системах или на FreeBSD.

Потом "всплыла" задача визуализации полётных данных и видео/звука...

К тому времени уже был опыт использования Си-шарпа под виндой.
Всё бы хорошо, но "прыгания" между семантиками низкоуровневых операций и тех типовых операций, под которые затачивался дотНЕТ и си-шарп, требовали очень крупных (и, часто - неприятных и даже болезненных) интеллектуальных усилий.
А применение библиотек и решений третьих фирм выявило проблему зависимости от качества их реализаций и обеспечения совместимости.
Короче, хотелось оставаться в одном и том же средстве разработки и иметь возможность комфортного и безболезненного "прыгания" по уровням представлений моделей в своих программах.

С учётом ещё и надвигающейся многоплатформенности реализаций (пошли разговоры со стороны заказчика о Линуксе), были выбраны Qt, Дельфи (с учётом обещаний от Эмбаркадеро) и Лазарь.
Наверное, можно было бы выбрать и Qt, но там мы не смогли в полной мере разобраться как нормально производить статическую линковку как самой библиотеки, так и приложений, использующих её. Временной фактор поджимал, "полезли нюансы непонятные", а нужного размера бубна для более качественного камлания не нашлось...

Посему остался Дельфи.

После стольких лет это был как глоток свежего воздуха, ей-богу!
Было полное впечатление, что язык, библиотека и среда просто помогают "додумавать" нужные и подходящие решения! Прямо мистика какая-то!
Проект частью переписывался с Си-шарпа, частью разрабатывались новые подсистемы и модули.
Огромное количество кода просто сократилось! В Дельфи оказалось более адекватно можно выразить многие низкоуровневые вещи и, за счёт нативного кода и отсутствия сборки мусора, всё работало в разы или на порядки быстрее. Более всего, конечно (повторюсь) понравилось более естественная запись выражений того, что делалось на низком уровне. У меня этого уровня в проекте МНОГО. Качество генерируемого кода - отменное. Из-за запрещения использования железа для ускорения графических и видеофункций, всё должно обрабатываться программно. Когда осталось время, одну из частей (оверлапинг "вживую" видеосигналов с двух камер с динамически генерируемой и изменяемой маской) переписал на встроенном ассемблере (вот, кстати, ещё одна из самых классных и удачно реализованных фич в Дельфи!). Прирост скорости составил где-то 3-7%. Вернул как было - там и так запас был совершенно удовлетворительный...

Лазарь – тоже ничего. Многоплатформенность – уже «искаропки». Но есть ещё ошибки в компиляторе, да и среда – не столь стабильна. У уж отладка с помощью gdb под виндой – вообще отдельная пестня! Кроме того, различаются реализации паскаля (можно поставить ключики-опции компилятору, но различия полностью не исчезают, да, к тому же, реализация совершенно не полная даже в режиме совместимости с дельфи).
Не смотря на это, я думаю, что следующим за Дельфи будет Лазарь. По большей части – из-за многоплатформенности, ну и – из-за бесплатности. Ценовая политика Эмбаркадеро – просто умиляет и поражает своей какой-то уж очень своеобразной логичностью (в частности с точки зрения позиционирования продукта и желанием его сделать более распространённым).

Новогодняя сказака.
Вы приходите в фирму (или проект) и вдруг с удивлением узнаёте, что проект планируется реализовывать на ............. ФОРТЕ!

Задам простой вопрос:
Ваша реакция и решение?
За всё ведь в жизни надо платить - не забыли?....
(добавлю, что проект и всё, что вокруг него - ну очень "вкусные" (от заказчика, зарплаты и режима работы и - до времени и перспектив).

Это - про реально. Теперь - более фантастический сюжет: поставьте вместоФорта - какой-либо из оберонов...

Очень хочется аослушать аргументацию в обоснование ваших решений и сам ход логических цепочек.

На http://www.proklondike.com/  в этом году - новое массовое поступление материала...
Пользуйтесь!

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

#ifndef __STATES_H__
#define __STATES_H__

#include "91x_type.h"

#include "errors.h"
#include "rtc.h"

#define STATES_BEGIN                                \
static void*   state_label = &&_L_state_START_; \
static TResult state_res;                       \
static vu32    state_finishMSec;                \
goto *state_label;                              \
_L_state_START_: {

#define STATES_END  } STATES_RESET;


#define STATES_STATE                     \
do{                                  \
__label__ _L_state_label_;       \
state_label = &&_L_state_label_; \
_L_state_label_: ;                       \
}while(0)


#define STATES_RESET                     \
do{                                  \
state_label = &&_L_state_START_; \
}while(0)


#define STATES_WAIT(condition)           \
do{                                  \
__label__ _L_state_label_;       \
state_label = &&_L_state_label_; \
_L_state_label_:                         \
if( ! (condition) ) return 1;    \
}while(0)


#define STATES_WAIT_TIMED(condition,ticks,timedout_label)           \
do{                                                             \
__label__ _L_state_label_;                                  \
state_finishMSec = RTC_msec + (ticks);                      \
state_label = &&_L_state_label_;                            \
_L_state_label_:                                                    \
if( ! (condition) ) {                                       \
if( RTC_msec >= state_finishMSec ) goto timedout_label; \
return 1;                                               \
}                                                           \
}while(0)


#define STATES_TIMER(ticks)                            \
do{                                                \
state_finishMSec = RTC_msec + (ticks);         \
STATES_WAIT( (RTC_msec >= state_finishMSec) ); \
}while(0)

#define STATES_DELAY(ticks)                   \
do{                                       \
vu32 finishMSec = RTC_msec + (ticks); \
while( RTC_msec < finishMSec );       \
}while(0)



#define STATES_OP(op,error_label) \
do{ \
__label__ _L_state_label_; \
state_label = &&_L_state_label_; \
_L_state_label_: \
if( (state_res = (op)) > 0 ) return state_res; \
if(  state_res         < 0 ) goto error_label; \
}while(0)
 
 
#endif [/font]

Что за эти годы изменилось?
ЧТо ныне в оберон-сообществе?
Кого уж нет, а кто - далече?
Что за делёжка и революсьон с оберонкором?
Кто какой тематикой на просторах СНГ занимается, используя обероны (в том или ином виде)?

Конкретно меня интересуют приложения оберонов/ады в системах реального времени, системах управления (желательно - авиация и чуть повыше), желательно более с уклоном в сторону "на голом железе".
Интерес обусловлен вопросами сертификации и (опять-таки!) повышения надёжности решений без значительного снижения быстродействия, по сравнению с системами, выполненными на Си и асме.

+ кроме Евгения кто-нибудь Хаскелем здесь ещё занимается?
Евгений, посматривай иногда в личку - есть (или вскорости появятся) вопросы для обсуждения и обмена с тобой мнениями, как с функциональшиком и хаскелистом! (с вероятным выносом в широкое обсуждение по взаимному согласию сторон )