Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Май 18, 2013, 02:19:34 am
-
Так, народ, что-то мне с BlackBox "везет" на всякие его особенности.
Вот поймал trap компилятора при попытке собрать простой модуль.
Воспроизводится везде, и в школьной сборке информатики-21 (BB 1.5), и в стоковом BB 1.6, и в красноярской сборке BB.
Исходник модуля и сам трап прикладываю. Также, на всякий случай, вот в интернеточитабельном виде исходник модуля:
MODULE Blur;
IMPORT Kernel, Out:=StdLog;
CONST
width = 640;
height = 480;
N = 13;
frames = 1000;
red = 0;
green = 1;
blue = 2;
TYPE
Frame = ARRAY width*height*(blue+1) OF SHORTCHAR;
PROCEDURE Index(x,y,color : INTEGER) : INTEGER;
BEGIN
RETURN ((x+y*width)*3+color)
END Index;
PROCEDURE Blur(IN in : Frame; OUT out : Frame);
VAR
x,y,c : INTEGER;
BEGIN
FOR y:=1 TO height-2 DO
FOR x:=1 TO width-2 DO
FOR c:=red TO blue DO
out[Index(x,y,c)] := SHORT(CHR( ( ORD(in[Index(x,y-1,c)]) + ORD(in[Index(x,y+1,c)]) +
ORD(in[Index(x-1,y,c)]) + ORD(in[Index(x+1,y,c)]) ) DIV 4 ));
END;
END;
END;
END Blur;
PROCEDURE Do*;
VAR
time : LONGINT;
f, n : INTEGER;
a1, a2 : POINTER TO Frame;
BEGIN
NEW(a1);
NEW(a2);
time := Kernel.Time();
FOR f:=1 TO frames DO
FOR n:=1 TO N DO
Blur(a1,a2);
Blur(a2,a1)
END
END;
Out.Real((Kernel.Time() - time)/1000)
END Do;
BEGIN
END Blur.
PS. Это я приводил к единому виду исходники той blur-задачки для всех языков программирования. Это, собственно наиваная читабельная реализация алгоритма. Очень важно чтобы оно заработало на ББ, иначе в статье ББ придется заменить другой реализацией Оберона, а этого сильно хочется избежать по ряду причин.
-
Так, народ, что-то мне с BlackBox "везет" на всякие его особенности.
Ему не нравится DIV 4. Если все выражение из CHR засунуть во временную переменную - начинает компилить. Причем слева у него тоже должно быть что-то сложное - просто CHAR(x DIV 4) нормально отрабатывает.
-
Если out[Index(x,y,c)] заменить на что-то вроде out[10] - то всё компилируется. Видимо баг, пиши в оминк )
-
Так, народ, что-то мне с BlackBox "везет" на всякие его особенности.
:) гы, - приветик мифу ( Инфо21 ) о том, что из идеологической простоты компилятора следует его "надежная" реализация...
-
Если out[Index(x,y,c)] заменить на что-то вроде out[10] - то всё компилируется. Видимо баг, пиши в оминк )
Написал.
-
DevCPC486.GetReg
....
IF 0 IN s THEN n := 0
ELSIF 2 IN s THEN n := 2
ELSIF 6 IN s THEN n := 6
ELSIF 7 IN s THEN n := 7
ELSIF 1 IN s THEN n := 1
ELSE n := 3
END;
....
change to
....
IF 0 IN s THEN n := 0
ELSIF 2 IN s THEN n := 2
ELSIF 1 IN s THEN n := 1
ELSIF 3 IN s THEN n := 3
ELSIF 6 IN s THEN n := 6
ELSE n := 7
END;
....
-
DevCPC486.GetReg
....
IF 0 IN s THEN n := 0
ELSIF 2 IN s THEN n := 2
ELSIF 6 IN s THEN n := 6
ELSIF 7 IN s THEN n := 7
ELSIF 1 IN s THEN n := 1
ELSE n := 3
END;
....
change to
....
IF 0 IN s THEN n := 0
ELSIF 2 IN s THEN n := 2
ELSIF 1 IN s THEN n := 1
ELSIF 3 IN s THEN n := 3
ELSIF 6 IN s THEN n := 6
ELSE n := 7
END;
....
Thanks. Can you explain this fix? It is safe?
-
Fix от maliya работает. BlackBox после пересборки тоже работает )
-
Can you explain this fix? It is safe?
[/quote]
it only change the regsiter select order;I think it is safe.
-
Can you explain this fix? It is safe?
it only change the regsiter select order;I think it is safe.
OK. But why this order is better then old one?
-
it only change the regsiter select order;I think it is safe.
OK. But why this order is better then old one?
Because it does not fail, dummy! ;)
P.S. Yes, very interesting why this does mattter.
-
DevCPC486.GetReg
....
IF 0 IN s THEN n := 0
ELSIF 2 IN s THEN n := 2
ELSIF 6 IN s THEN n := 6
ELSIF 7 IN s THEN n := 7
ELSIF 1 IN s THEN n := 1
ELSE n := 3
END;
....
change to
....
IF 0 IN s THEN n := 0
ELSIF 2 IN s THEN n := 2
ELSIF 1 IN s THEN n := 1
ELSIF 3 IN s THEN n := 3
ELSIF 6 IN s THEN n := 6
ELSE n := 7
END;
....
А какова гарантия того, что не появятся другие ошибки, связанные с этим исправлением? :)
-
Насколько я понял, суть трапа в том, что в подобной сложной цепочке конверсий почему-то первым вариантом для хранения значения конверсии подбирался внутренний элемент компилятора неверного размера, что и было ограничено трэпом.
Maliya просто поменял последовательность подбора вариантов, которая в принципе, в варианте с ELSIF ветками вообще не должна зависеть от последовательности. Видимо, нет полной однозначности, это исправимо.
Вообще, можно отметить нарочную говнокодную сущность представленного примера, а так же проработанность компилятора, который позволил:
а) не записать мусор в бинарный файл
б) не выпал в шоковом припадке, а корректно остановился на явном и описанном предусловии
в) построен так, что починить его сможет любой китаец, хы-хы :D
:) гы, - приветик мифу ( Инфо21 ) о том, что из идеологической простоты компилятора следует его "надежная" реализация...
Учительница рассуждает о том, чего не понимает. Жуть.
-
:) гы, - приветик мифу ( Инфо21 ) о том, что из идеологической простоты компилятора следует его "надежная" реализация...
Учительница рассуждает о том, чего не понимает. Жуть.
гыы Петобыдло опять говном зарядилось... повеселимся... :)
-
Вообще, можно отметить нарочную говнокодную сущность представленного примера
Можешь переписать так, чтобы оно перестало быть говнокодом?
На входе для каждого кадра одномерный массив uint8_t.
-
Куд-кудах
-
Куд-кудах
гыыы Петабыдло научилось править цитируемый тексть.. с достиженьецем ;D
-
Вообще, можно отметить нарочную говнокодную сущность представленного примера
Можешь переписать так, чтобы оно перестало быть говнокодом?
На входе для каждого кадра одномерный массив uint8_t.
гы вопрошать Петабыдло ?... зачетно (как новый тип развлечения) :D
-
Сам в шоке, но в этот раз я с Петром солидарен.
-
Можешь переписать так, чтобы оно перестало быть говнокодом?
На входе для каждого кадра одномерный массив uint8_t.
Но ведь на этом форуме ты профессионал.
-
Сам в шоке, но в этот раз я с Петром солидарен.
какой тут шок.. все ОК. :)
-
Можешь переписать так, чтобы оно перестало быть говнокодом?
На входе для каждого кадра одномерный массив uint8_t.
Но ведь на этом форуме ты профессионал.
Мне интересно твое мнение. Свое мнение в таком вопросе проще всего озвучивать кодом.
-
[15:57:47]
<Kemet> ккк это Кушнир ?
[15:58:00] <valexey_> да
[15:58:07] <valexey_> по всем черточкам похож
[15:58:21] <valexey_> хотя он когда регистрировался специально фейковый временный e-mail адрес подставил
[15:58:51] <Kemet> шоб инфо21 не узнал )
[15:59:16] <valexey_> скорее чтобы Дизер на него мгновенно не сагрился :-)
;D ;D ;D ;D ;D Ну вы даете... - ЧТОБЫ СРАТЬ МОЖНО БЫЛО ИСПОДВОЛЬ (не узнанным ), бедняжка просто не в состоянии понять гопнобыдло - это его сущность, которая вылезет в любом случае, в любом обличье.
-
Ну а ты срёшь только в ответ, от безысходности, не иначе :)
-
Ну а ты срёшь только в ответ, от безысходности, не иначе :)
Я уже говорил - ради развлечения - что бы добро(говно) просто так не пропадало (т.е. тренировка реакции).
-
Мне интересно твое мнение. Свое мнение в таком вопросе проще всего озвучивать кодом.
Это было бы тактическое упущение, предоставить тебе код для оценки на твоей площадке в компании твоих друзьёв.
-
Мне интересно твое мнение. Свое мнение в таком вопросе проще всего озвучивать кодом.
Это было бы тактическое упущение, предоставить тебе код для оценки на твоей площадке в компании твоих друзьёв.
;D ;D ;D ;D ;D о гопнобыдло - тактик :D
-
Ну а ты срёшь только в ответ, от безысходности, не иначе :)
Я уже говорил - ради развлечения - что бы добро(говно) просто так не пропадало (т.е. тренировка реакции).
твоё говно не пахнет, я понял.
-
Ну а ты срёшь только в ответ, от безысходности, не иначе :)
Я уже говорил - ради развлечения - что бы добро(говно) просто так не пропадало (т.е. тренировка реакции).
твоё говно не пахнет, я понял.
вроде как нет (пахнет), впрочем , у вас возможно своим рецепторы забиты.. попробуйте к врачу обратиться...
-
Ну а ты срёшь только в ответ, от безысходности, не иначе :)
Я уже говорил - ради развлечения - что бы добро(говно) просто так не пропадало (т.е. тренировка реакции).
Народ, от вас в последнее время, по крайней мере в моих технических темах, польза какая-то отрицательная.
Пётр, напиши уже решение не в говнокод-стайле, и будет тебе респект (если оно конечно корректно работать будет). Алгоритм должен остаться тот же. Упор - на максимальную читабельность и понятность. В моих, да и в твоих, полагаю, интересах, иметь максимально читабельную, не говнокодистую, версию кода для КП.
А от оценок качества компилятора я пока воздержусь.
-
Суть в том, что для меня эта площадка чужая, а для тебя - своя.
Поэтому мне не жалко испортить тред, или посраться с тобой на пару страниц, это преимущества свободы слова.
А вот ты засоряешь пространство своих единомышленников, а это уже профит, ведь люди будут уставать от говна в два раза быстрее, чем если бы я один тут куражился.
;)
Так что продолжай упражняться в красноречии, а я буду радоваться твоим успехам.
-
Народ, от вас в последнее время, по крайней мере в моих технических темах, польза какая-то отрицательная.
и это удивляет? ;)
-
... а я буду радоваться твоим успехам.
главное чтобы не разорвало от этого.. а то без дураков скучно..
-
Народ, от вас в последнее время, по крайней мере в моих технических темах, польза какая-то отрицательная.
Это у тебя, Алексей, проявляются издержки дружбы с мудаками, хы ;)
Пётр, напиши уже решение не в говнокод-стайле, и будет тебе респект (если оно конечно корректно работать будет).
У тебя ведь есть удочка, зачем тебе моя рыба? :)
-
А от оценок качества компилятора я пока воздержусь.
и правильно сделаете (скажем так, приветик я передавал не компилятору а тезису одного известного идеолога-обероноевангелиста...)... :)
-
а то без дураков скучно..
А я всё думал, чего тебя на этой площадке пригрели. Кормят, поят, спишь на тёплом коврике. Цепная училка, это ж ценно. А ты уже успел понять, что училки не для знаний нужны?
-
Пётр, напиши уже решение не в говнокод-стайле, и будет тебе респект (если оно конечно корректно работать будет).
У тебя ведь есть удочка, зачем тебе моя рыба? :)
Чтобы из моей и твоей рыбы выбрать наилучшую и уже её показывать народу, дабы не посрамить реку нашу.
-
а то без дураков скучно..
А я всё думал, чего тебя на этой площадке пригрели. Кормят, поят, спишь на тёплом коврике. Цепная училка, это ж ценно. А ты уже успел понять, что училки не для знаний нужны?
:) ох не стоит вам заниматься делом... к которому нет способностей (думать) - продолжайте делать то что умеете изначально - СРАТЬ ( нам сойдете и таким)
-
дизер, всё таки ты не в той ситуации, чтобы изображать из себя ментора.
А вообщекуд-кудах-тах-тах
это забавно. Больше, больше говна.
-
дизер, всё таки ты не в той ситуации, чтобы изображать из себя ментора.
А вообщекуд-кудах-тах-тах
это забавно. Больше, больше говна.
господь с вами... это было лишь пожелание.. :D
-
Да .. Алексей (если уж говорить о читабельности) - все же поправьте названия именованных констант... - по смыслу алгоритма.. у вас не цвета а идентификаторы каналов (channel_id) -red_chan_id, green_chan_id, blue_chan_id,... ну доп константу введите num_channels=3 и циклическую переменную замените на channel_id (а то заголовок цикла имхо уродливо смотрится)
-
... и еще, что-то не понимаю - альтернатива в виде массива (1 или 2 -мерного) записей приемлема (рассматривалась) или нет? - то что она нагляднее будет это факт.. а вот по скорости.. х.з. - но хоть индексная функция будет ненужна...
-
... и еще, что-то не понимаю - альтернатива в виде массива (1 или 2 -мерного) записей приемлема (рассматривалась) или нет? - то что она нагляднее будет это факт.. а вот по скорости.. х.з. - но хоть индексная функция будет ненужна...
По условию задачи нам банально на вход для каждого кадра приходит uint8_t* p; также мы знаем, что там RGB, каждый цвет - один байт, и размер кадра 640x480.
-
... и еще, что-то не понимаю - альтернатива в виде массива (1 или 2 -мерного) записей приемлема (рассматривалась) или нет? - то что она нагляднее будет это факт.. а вот по скорости.. х.з. - но хоть индексная функция будет ненужна...
По условию задачи нам банально на вход для каждого кадра приходит uint8_t* p; также мы знаем, что там RGB, каждый цвет - один байт, и размер кадра 640x480.
я про другое , может обьявить
TCOLOR=RECORD
R,G,B:SHORTCHAR;
END;
и FRAME=ARRAY w*h of TCOLOR ; (ну или соответствующий 2 мерный массив) ?
-
... и еще, что-то не понимаю - альтернатива в виде массива (1 или 2 -мерного) записей приемлема (рассматривалась) или нет? - то что она нагляднее будет это факт.. а вот по скорости.. х.з. - но хоть индексная функция будет ненужна...
По условию задачи нам банально на вход для каждого кадра приходит uint8_t* p; также мы знаем, что там RGB, каждый цвет - один байт, и размер кадра 640x480.
я про другое , может обьявить
TCOLOR=RECORD
R,G,B:SHORTCHAR;
END;
и FRAME=ARRAY w*h of TCOLOR ; (ну или соответствующий 2 мерный массив) ?
По моему не выйдет - там же еще выравнивание небось будет.
-
По моему не выйдет - там же еще выравнивание небось будет.
а х.з. но в любом случае это будет эксплоитом (язык не определяет структуру данных на низком уровне)... что не гуд...
-
В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))
-
В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))
На самом деле, не совсем:
http://www.stroustrup.com/C++11FAQ.html#align
http://www.stroustrup.com/C++11FAQ.html#attributes
-
Возвращаясь к первоначальному топику - пришел ответ от Oberon microsystems AG:
Dear Alexey,
thank you very much for your error report.
We will analyze the problem and hope to correct it in the course of our maintenance activity.
You are probably already aware of a possible workaround along the following lines:
PROCEDURE Blur(IN in : Frame; OUT out : Frame);
VAR
x,y,c,o: INTEGER;
BEGIN
FOR y:=1 TO height-2 DO
FOR x:=1 TO width-2 DO
FOR c:=red TO blue DO
o:=(ORD(in[Index(x,y-1,c)])
+ ORD(in[Index(x,y+1,c)])
+ ORD(in[Index(x-1,y,c)])
+ ORD(in[Index(x+1,y,c)])) DIV 4;
out[Index(x,y,c)] := SHORT(CHR(o));
END;
END;
END;
END Blur;
Thanks again and with best regards,
Marc Frei
-
Интересно как скоро будет фикс.
-
valexey_u, десятилетия и тонны софта до версии С++11х, так что это не показатель. То же самое и с новыми типами вроде int32_least_t, они нигде не используются, а нужно, чтобы весь код был с их применением.
-
Интересно как скоро будет фикс.
Ответил им. Дал быстрый фикс от maliya, и ссылку на эту ветку.
-
Ответил им. Дал быстрый фикс от maliya, и ссылку на эту ветку.
Представляю их лица, когда они переведут эту ветку... (Привет kkk и Ди-ди-дАйзеру)
-
Ответил им. Дал быстрый фикс от maliya, и ссылку на эту ветку.
Представляю их лица, когда они переведут эту ветку... (Привет kkk и Ди-ди-дАйзеру)
:) да ладно... ради общего же дела старались (по крайней мере я, увидев бы эту ветку на их месте...-- сказал себе.. блин , а все таки здорово, что наше поделье через 15 лет , вызывает такие эмоциии - ну не круто ли!!!)
-
... и уж они явно лучше чем "лизоблюдские" реляции из коровника, для человека который более менее адекватно оценивает свой труд...(но это , разумеется , ИМХО)
-
В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))
где то так.. , но вроде как еще в допотопных версиях Паскаля проблема решалась использованием packed records.. на уровне языка.
-
Небольшое отклонение от темы.
FreePascal, VirtualPascal, Delphi — проблемы нет, PACKED справляется с записями и массивами. То же самое с соглашениями о вызове. Все их применяют, но лишь стандарт С++ не знает об их существовании. Если целевая платформа не поддерживает определённое соглашение (разрядность, операцию умножения или любой другой элемент ЯП) достаточно выдать ошибку компиляции. Но STDCALL — он и в Африке STDCALL.
Я сперва использовал __declspec(alegn(1)), потом перешёл на #pragma pack(push, 1) из-за разичий в GCC и Студии.
-
перешёл на #pragma pack(push, 1) из-за разичий в GCC и Студии.
:) аналогично.. только аligned не использовал ни разу..
-
Интересно как скоро будет фикс.
а вот это , действительно интересно...
-
Небольшое отклонение от темы.
FreePascal, VirtualPascal, Delphi — проблемы нет, PACKED справляется с записями и массивами. То же самое с соглашениями о вызове. Все их применяют, но лишь стандарт С++ не знает об их существовании. Если целевая платформа не поддерживает определённое соглашение (разрядность, операцию умножения или любой другой элемент ЯП) достаточно выдать ошибку компиляции. Но STDCALL — он и в Африке STDCALL.
Я сперва использовал __declspec(alegn(1)), потом перешёл на #pragma pack(push, 1) из-за разичий в GCC и Студии.
FreePascal, VirtualPascal, Delphi - не следуют какому-либо стандарту вообще. Это конкретные реализации со своими заморочками, не следующие какому-либо стандарту. Реализации сравнивать со стандартом на язык как-то странно. Ну, то есть корректно было бы сравнивать FreePascal c g++, Delphi с MSVS, VirtualPascal с Intel C++ Compiler и так далее.
Ну и я же не даром две ссылки привел - стандарт С++ теперь про выравнивание знает. Но прибить гвоздями ABI для универсального языка не представляется возможным.
-
По моему не выйдет - там же еще выравнивание небось будет.
Есть же флаги untagged, noalign. Ну и ожно проверить, сравнив адреса записей(адрес конкретного элемента массива) с вычисленным.
-
По моему не выйдет - там же еще выравнивание небось будет.
Есть же флаги untagged, noalign. Ну и ожно проверить, сравнив адреса записей(адрес конкретного элемента массива) с вычисленным.
Можно. Но это будет BlackBox only решение. То несть не КП'шное.
-
Ответил им. Дал быстрый фикс от maliya, и ссылку на эту ветку.
Представляю их лица, когда они переведут эту ветку... (Привет kkk и Ди-ди-дАйзеру)
Да ваще жесть )))
-
В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))
где то так.. , но вроде как еще в допотопных версиях Паскаля проблема решалась использованием packed records.. на уровне языка.
Упакованные записи ещё же с самой первой версии паскаля (виртовской), насколько я помню, есть. И до сих пор в дельфях...
-
В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))
где то так.. , но вроде как еще в допотопных версиях Паскаля проблема решалась использованием packed records.. на уровне языка.
Упакованные записи ещё же с самой первой версии паскаля (виртовской), насколько я помню, есть. И до сих пор в дельфях...
Берем стандарт паскаля: http://www.cs.bilkent.edu.tr/~guvenir/courses/CS315/iso7185pascal.pdf
Ищем слово align - не находим ничего. Можешь попробовать самостоятельно найти. Думаю, что с соглашениями о вызове процедур будет примерно то же самое.
-
Кстати, а вот виртовский паскаль: http://www.bandwidthco.com/history/programming/Wirth%20Pascal%20Programming%20Language.pdf
-
Кстати, а вот виртовский паскаль: http://www.bandwidthco.com/history/programming/Wirth%20Pascal%20Programming%20Language.pdf
вот и ищите там слово "packed" - про aligned никто ничего не говорил (в контексте Паскалей)
-
По моему не выйдет - там же еще выравнивание небось будет.
Есть же флаги untagged, noalign. Ну и ожно проверить, сравнив адреса записей(адрес конкретного элемента массива) с вычисленным.
Можно. Но это будет BlackBox only решение. То несть не КП'шное.
ну и что... опять же - ровно то же что и в случае использования прагм C\C++ - решение совершенно одинаковое по "качеству"
-
Кстати, а вот виртовский паскаль: http://www.bandwidthco.com/history/programming/Wirth%20Pascal%20Programming%20Language.pdf
вот и ищите там слово "packed" - про aligned никто ничего не говорил (в контексте Паскалей)
единственное... что если мне не изменяет память то в Турбо Паскале (каком то из них) было сказано что слово packed оставлено только для совместимости со стандартом.. то есть предполагалось использование директив $A+ ($A-) для достижения эффекта на уровне модулей...
-
Кстати, а вот виртовский паскаль: http://www.bandwidthco.com/history/programming/Wirth%20Pascal%20Programming%20Language.pdf
вот и ищите там слово "packed" - про aligned никто ничего не говорил (в контексте Паскалей)
единственное... что если мне не изменяет память то в Турбо Паскале (каком то из них) было сказано что слово packed оставлено только для совместимости со стандартом.. то есть предполагалось использование директив $A+ ($A-) для достижения эффекта на уровне модулей...
В какой-то из версий дельфов packed record точно работало -- у меня в какой-то программе использовалось...
-
Упакованные записи ещё же с самой первой версии паскаля (виртовской), насколько я помню, есть. И до сих пор в дельфях...
Берем стандарт паскаля: http://www.cs.bilkent.edu.tr/~guvenir/courses/CS315/iso7185pascal.pdf
Ищем слово align - не находим ничего. Можешь попробовать самостоятельно найти. Думаю, что с соглашениями о вызове процедур будет примерно то же самое.
Не align, а packed.
Вот в этом вот файле указаны packed array, packed file. Хотя прямого указания на packed record я там не заметил, но во всех книгах по паскалю, что я читал раньше, они тоже были...
Насчёт соглашений о вызове процедур в паскале - ничего не знаю, не слышал...
-
Вот в этом вот файле указаны packed array, packed file. Хотя прямого указания на packed record я там не заметил, но во всех книгах по паскалю, что я читал раньше, они тоже были...
Я имел в виду вот этот файл:
Кстати, а вот виртовский паскаль: http://www.bandwidthco.com/history/programming/Wirth%20Pascal%20Programming%20Language.pdf
-
А вот выдержка из стандарта:
6.4.3 Structured-types
6.4.3.1 General
A new-structured-type shall be classied as an array-type, record-type, set-type, or file-type according to the unpacked-structured-type closest-contained by the new-structured-type. A component of a value of a structured-type shall be a value.
structured-type = new-structured-type j structured-type-identifier .
new-structured-type = [ 'packed' ] unpacked-structured-type .
unpacked-structured-type = array-type | record-type | set-type | file-type .
The occurrence of the token packed in a new-structured-type shall designate the type denoted thereby as packed. The designation of a structured-type as packed shall indicate to the processor that data-storage of values should be economized, even if this causes operations on, or accesses to components of, variables possessing the type to be less efficient in terms of space or time.
The designation of a structured-type as packed shall affect the representation in data-storage of that structured-type only; i.e., if a component is itself structured, the component's representation in data-storage shall be packed only if the type of the component is designated packed.
-
А вот выдержка из стандарта:
...
The designation of a structured-type as packed shall indicate to the processor that data-storage of values should be economized, even if this causes operations on, or accesses to components of, variables possessing the type to be less efficient in terms of space or time.
Да, был не прав, поддержка в стандартном паскаля какая-то есть.
Но, однако ж, прошу обратить внимание: данный пункт не дает однозначной трактовки как именно packed тип должен минимизировать свое место. Ну, то есть реализация которая для минимизации объема будет использовать какой-либо алгоритм сжатия (deflate например) не будет противоречить стандарту (по крайней мере в данном пункте).
Для контраста, возьмем с++ и его ключевое слово alignas - там четко определено что это именно выравнивание, что никакого сжатия не предусмотрено и так далее. Желающие могут ознакомиться со стандартом тут: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf (основной пункт 7.6.2 (стр. 176) и 3.11 (стр. 79), для разъяснения терминологии).
Ну или более простым языком: http://en.cppreference.com/w/cpp/language/alignas
-
Для контраста, возьмем с++ и его ключевое слово alignas
alignas( expression ) (since C++11)
-
Кто нибудь натыкался на русские версии стандартов языков Си,С++ новее чем 1998 г. - хотя бы пре релизные? - киньте ссылку плиз...
-
Кто нибудь натыкался на русские версии стандартов языков Си,С++ новее чем 1998 г. - хотя бы пре релизные? - киньте ссылку плиз...
Евгений Зуев переводит (может уже перевёл) современный стандарт С++ на русский, но вряд ли этот перевод будет выложен в онлайн. Хотя запиратят и на торрент наверняка выложат...
http://zouev.blogspot.ru/2010/01/blog-post_07.html
http://zouev.blogspot.ru/2011/01/blog-post.html
Не знаю, в каком состоянии эта работа, других вроде нет (по С++)
-
Для контраста, возьмем с++ и его ключевое слово alignas
alignas( expression ) (since C++11)
Ну, да. В современном С++ это есть. В С++ 15ти летней давности (С++98 - предыдущий стандарт) этого не было. Не вижу смысла ориентироваться на допотопные версии языка.
-
Если перевести на русский: до 2011 года в С++ выравнивания не было (как и массы других вещей). А как следствие, в 99% существующего кода не используется. Хорошо, что добавили, но никого не волнует скорость выхода стандартов С++. Важно, сколько лет функциональности не было и когда она появилась.
-
Если перевести на русский: до 2011 года в С++ выравнивания не было (как и массы других вещей). А как следствие, в 99% существующего кода не используется. Хорошо, что добавили, но никого не волнует скорость выхода стандартов С++. Важно, сколько лет функциональности не было и когда она появилась.
Важно что есть сейчас. До того были нестандартные расширизмы (правда через стандартные механизмы создания расширений, например через директиву препроцессора #pragma), впрочем как и в паскале по факту.
Если уж с чем и сравнивать С++ в этом плане, так это с Адой - вот Ада да, она крута, там выравнивание как минимум со стандарта Ада-95 (а может и с Ада-83). Причем в нормальном, а не в паскалевском виде: http://oopweb.com/Ada/Documents/Ada95RM/Volume/13-03.htm
Причем это действительно фактический стандарт, он используется. В отличае от стандарта паскаля (который по сути - фикция).
-
Ada вообще прекрасна! Смотрите (http://oopweb.com/Ada/Documents/Ada95RM/Volume/13-05-01.htm):
Word : constant := 4; -- storage element is byte, 4 bytes per word
type State is (A,M,W,P);
type Mode is (Fix, Dec, Exp, Signif);
type Byte_Mask is array (0..7) of Boolean;
type State_Mask is array (State) of Boolean;
type Mode_Mask is array (Mode) of Boolean;
type Program_Status_Word is
record
System_Mask : Byte_Mask;
Protection_Key : Integer range 0 .. 3;
Machine_State : State_Mask;
Interrupt_Cause : Interruption_Code;
Ilc : Integer range 0 .. 3;
Cc : Integer range 0 .. 3;
Program_Mask : Mode_Mask;
Inst_Address : Address;
end record;
for Program_Status_Word use
record
System_Mask at 0*Word range 0 .. 7;
Protection_Key at 0*Word range 10 .. 11; -- bits 8,9 unused
Machine_State at 0*Word range 12 .. 15;
Interrupt_Cause at 0*Word range 16 .. 31;
Ilc at 1*Word range 0 .. 1; -- second word
Cc at 1*Word range 2 .. 3;
Program_Mask at 1*Word range 4 .. 7;
Inst_Address at 1*Word range 8 .. 31;
end record;
for Program_Status_Word'Size use 8*System.Storage_Unit;
for Program_Status_Word'Alignment use 8;
-
Причем это действительно фактический стандарт, он используется. В отличае от стандарта паскаля (который по сути - фикция).
Не соглашусь с Вами, Алексей. Что лучше — несовместимые расширения без стандарта де-юре или де-факто совместимые расширения, аналог теневого стандарта? Если PACKED есть во всех популярных компиляторах, то он и есть стандарт. А вот с прагмами и declspec я натыкался на грабли, когда писал простейший SDK. Учитывая, что третьи лица используют стандарт древнее 11х невозможно не тащить за собой весь воз костылей. Так что паскалисты молодцы — там и соглашения о вызовах и выравнивания единообразно присутствуют, из-за чего код де-факто переносим. А что ещё нужно практикам?
-
Причем это действительно фактический стандарт, он используется. В отличае от стандарта паскаля (который по сути - фикция).
Не соглашусь с Вами, Алексей. Что лучше — несовместимые расширения без стандарта де-юре или де-факто совместимые расширения, аналог теневого стандарта? Если PACKED есть во всех популярных компиляторах, то он и есть стандарт. А вот с прагмами и declspec я натыкался на грабли, когда писал простейший SDK. Учитывая, что третьи лица используют стандарт древнее 11х невозможно не тащить за собой весь воз костылей. Так что паскалисты молодцы — там и соглашения о вызовах и выравнивания единообразно присутствуют, из-за чего код де-факто переносим. А что ещё нужно практикам?
Я не слишком понимаю о чем речь. Берем произвольное приложение писанное скажем на FreePascal'e - оно соберется на Delphi? А на VirtualPascal'e? А на Object Pascal'e (нет, не том что TurboPascal, а тот который от apple)? Вот что-то я сомневаюсь.
packed в стандартном паскале есть, и это не расширизм. Только он (packed) вот не гарантирует ничего в том виде, в котором он там описан. Кроме того, насколько я понимаю, по сути софта писанного на стандартном паскале просто нет. Все используют несовместимые (со стандартом и друг с другом) диалекты.
А прописать соглашения о вызовах в диалектах паскаля тоже можно (а главное - нужно, иначе там это не появилось бы). Причина появления явного прописывания соглашения о вызове в сигнатуре функции ровно та же что и в случае появления её в реализациях Си.
-
Соберётся, если писалось с использованием общей части языка (в большей степени равняются на Delphi). В VirtualPascal есть режим Делфи (не полный) и в FreePascal тоже. Я переносил свои программы между тремя. А суть в следующем: PACKED для структур во всех трёх обеспечивает alignas(1), STDCALL/CDECL/THISCALL и т.д. — правильное соглашение о вызове для функций. Паскаль не приветствует сложных кодирований расширений, вроде __xxxxx(yyy(__zzz)), поэтому есть определённое единообразие.
Это просто констатация факта, а не нападки на С++.
-
Соберётся, если писалось с использованием общей части языка (в большей степени равняются на Delphi). В VirtualPascal есть режим Делфи (не полный) и в FreePascal тоже. Я переносил свои программы между тремя. А суть в следующем: PACKED для структур во всех трёх обеспечивает alignas(1), STDCALL/CDECL/THISCALL и т.д. — правильное соглашение о вызове для функций. Паскаль не приветствует сложных кодирований расширений, вроде __xxxxx(yyy(__zzz)), поэтому есть определённое единообразие.
Это просто констатация факта, а не нападки на С++.
Глянул стандарт паскаля - ничего не нашел про STDCALL и так далее. Можешь ткнуть носом?
Ну, то есть похоже, что эти атрибуты соглашения о вызове явно тоже расширизм. Как и в сях/плюсах.
В плюсах и сях вообще просто - это все заруливается макросом, содержимое которого зависит (и автоматически выбирается) в зависимости от типа компилятора. У нас на работе код небольшого-среднего проекта (то есть порядка 100-200 тыс. строк кода) собирается и gcc (под линукс) и msvs под винду. И проблем со всем этим никаких. Естественно там используются в том числе и сторонние библиотеки.
-
Да, это расширения. Просто они одинаковые и ведут себя одинаково. Получается неформальный стандарт без применения условной компиляции.
-
Да, это расширения. Просто они одинаковые и ведут себя одинаково. Получается неформальный стандарт без применения условной компиляции.
Ну, можно и так. Хотя я все же предпочитаю условную компиляцию, то есть чтобы если нас собирают неизвестным (и не оттестированым) компилятором, то в месте где мы используем расширизм, вывелся бы warning во время компиляции. Благо таковая условная компиляция ровно ничего не стоит.
-
Ada вообще прекрасна! Смотрите (http://oopweb.com/Ada/Documents/Ada95RM/Volume/13-05-01.htm):
Word : constant := 4; -- storage element is byte, 4 bytes per word
type State is (A,M,W,P);
type Mode is (Fix, Dec, Exp, Signif);
type Byte_Mask is array (0..7) of Boolean;
type State_Mask is array (State) of Boolean;
type Mode_Mask is array (Mode) of Boolean;
type Program_Status_Word is
record
System_Mask : Byte_Mask;
Protection_Key : Integer range 0 .. 3;
Machine_State : State_Mask;
Interrupt_Cause : Interruption_Code;
Ilc : Integer range 0 .. 3;
Cc : Integer range 0 .. 3;
Program_Mask : Mode_Mask;
Inst_Address : Address;
end record;
for Program_Status_Word use
record
System_Mask at 0*Word range 0 .. 7;
Protection_Key at 0*Word range 10 .. 11; -- bits 8,9 unused
Machine_State at 0*Word range 12 .. 15;
Interrupt_Cause at 0*Word range 16 .. 31;
Ilc at 1*Word range 0 .. 1; -- second word
Cc at 1*Word range 2 .. 3;
Program_Mask at 1*Word range 4 .. 7;
Inst_Address at 1*Word range 8 .. 31;
end record;
for Program_Status_Word'Size use 8*System.Storage_Unit;
for Program_Status_Word'Alignment use 8;
Этот пример ещё в Аде-83 указан:
http://archive.adaic.com/standards/83lrm/html/lrm-13-04.html
Оно и понятно -- Ада изначально разрабатывалась для того, что бы работать с железом на низком уровне, вот и заложили в неё сразу же средства низкоуровнего представления типов данных...
WORD : constant := 4; -- storage unit is byte, 4 bytes per word
type STATE is (A,M,W,P);
type MODE is (FIX, DEC, EXP, SIGNIF);
type BYTE_MASK is array (0.. 7) of BOOLEAN;
type STATE_MASK is array (STATE) of BOOLEAN;
type MODE_MASK is array (MODE) of BOOLEAN;
type PROGRAM_STATUS_WORD is
record
SYSTEM_MASK : BYTE_MASK;
PROTECTION_KEY : INTEGER range 0 .. 3;
MACHINE_STATE : STATE_MASK;
INTERRUPT_CAUSE : INTERRUPTION_CODE;
ILC : INTEGER range 0 .. 3;
CC : INTEGER range 0 .. 3;
PROGRAM_MASK : MODE_MASK;
INST_ADDRESS : ADDRESS;
end record;
for PROGRAM_STATUS_WORD use
record at mod 8;
SYSTEM_MASK at 0*WORD range 0 .. 7;
PROTECTION_KEY at 0*WORD range 10 .. 11; -- bits 8,9 unused
MACHINE_STATE at 0*WORD range 12 .. 15;
INTERRUPT_CAUSE at 0*WORD range 16 .. 31;
ILC at 1*WORD range 0 .. 1; -- second word
CC at 1*WORD range 2 .. 3;
PROGRAM_MASK at 1*WORD range 4 .. 7;
INST_ADDRESS at 1*WORD range 8 .. 31;
end record;
for PROGRAM_STATUS_WORD'SIZE use 8*SYSTEM.STORAGE_UNIT;
-
Ada вообще прекрасна! Смотрите (http://oopweb.com/Ada/Documents/Ada95RM/Volume/13-05-01.htm):
Word : constant := 4; -- storage element is byte, 4 bytes per word
type State is (A,M,W,P);
type Mode is (Fix, Dec, Exp, Signif);
type Byte_Mask is array (0..7) of Boolean;
type State_Mask is array (State) of Boolean;
type Mode_Mask is array (Mode) of Boolean;
type Program_Status_Word is
record
System_Mask : Byte_Mask;
Protection_Key : Integer range 0 .. 3;
Machine_State : State_Mask;
Interrupt_Cause : Interruption_Code;
Ilc : Integer range 0 .. 3;
Cc : Integer range 0 .. 3;
Program_Mask : Mode_Mask;
Inst_Address : Address;
end record;
for Program_Status_Word use
record
System_Mask at 0*Word range 0 .. 7;
Protection_Key at 0*Word range 10 .. 11; -- bits 8,9 unused
Machine_State at 0*Word range 12 .. 15;
Interrupt_Cause at 0*Word range 16 .. 31;
Ilc at 1*Word range 0 .. 1; -- second word
Cc at 1*Word range 2 .. 3;
Program_Mask at 1*Word range 4 .. 7;
Inst_Address at 1*Word range 8 .. 31;
end record;
for Program_Status_Word'Size use 8*System.Storage_Unit;
for Program_Status_Word'Alignment use 8;
Этот пример ещё в Аде-83 указан:
http://archive.adaic.com/standards/83lrm/html/lrm-13-04.html
Оно и понятно -- Ада изначально разрабатывалась для того, что бы работать с железом на низком уровне, вот и заложили в неё сразу же средства низкоуровнего представления типов данных...
WORD : constant := 4; -- storage unit is byte, 4 bytes per word
type STATE is (A,M,W,P);
type MODE is (FIX, DEC, EXP, SIGNIF);
type BYTE_MASK is array (0.. 7) of BOOLEAN;
type STATE_MASK is array (STATE) of BOOLEAN;
type MODE_MASK is array (MODE) of BOOLEAN;
type PROGRAM_STATUS_WORD is
record
SYSTEM_MASK : BYTE_MASK;
PROTECTION_KEY : INTEGER range 0 .. 3;
MACHINE_STATE : STATE_MASK;
INTERRUPT_CAUSE : INTERRUPTION_CODE;
ILC : INTEGER range 0 .. 3;
CC : INTEGER range 0 .. 3;
PROGRAM_MASK : MODE_MASK;
INST_ADDRESS : ADDRESS;
end record;
for PROGRAM_STATUS_WORD use
record at mod 8;
SYSTEM_MASK at 0*WORD range 0 .. 7;
PROTECTION_KEY at 0*WORD range 10 .. 11; -- bits 8,9 unused
MACHINE_STATE at 0*WORD range 12 .. 15;
INTERRUPT_CAUSE at 0*WORD range 16 .. 31;
ILC at 1*WORD range 0 .. 1; -- second word
CC at 1*WORD range 2 .. 3;
PROGRAM_MASK at 1*WORD range 4 .. 7;
INST_ADDRESS at 1*WORD range 8 .. 31;
end record;
for PROGRAM_STATUS_WORD'SIZE use 8*SYSTEM.STORAGE_UNIT;
Я видел. Но пример таки отличаются (кстати, обратите внимание на капс в Аде-83 :-) ).
Кроме того, атрибутов про выравнивание там, в Аде-83, похоже не было.
-
Кроме того, атрибутов про выравнивание там, в Аде-83, похоже не было.
Таки было: http://archive.adaic.com/standards/83rat/html/ratl-15-04.html#15.4.3
Alignment Clauses:
When it is important that the objects of a given record type be allocated on a given storage boundary, this can be specified by means of an alignment clause. The alignment is expressed as a number of storage units, and all addresses at which the objects are allocated must be exact multiples of the specified number of storage units (the address modulo the alignment expression must be zero).
for PAGE_BUFFER use at mod 512;
Затем, в http://archive.adaic.com/standards/95lrm/LRMascii/chg83.txt это было переделано. Alignment Clauses были переименованы в Mod Clauses (http://www.adahome.com/rm95/rm9x-J-08.html#1):
A record_representation_clause of the form:
for r use
record at mod a
...
end record;
is equivalent to:
for r'Alignment use a;
for r use
record
...
end record;
-
Я видел. Но пример таки отличаются (кстати, обратите внимание на капс в Аде-83 :-) ).
Кроме того, атрибутов про выравнивание там, в Аде-83, похоже не было.
Собственно в этих двух примерах было показано:
for Program_Status_Word use
record
...
for Program_Status_Word'Alignment use 8;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^for PROGRAM_STATUS_WORD use
record at mod 8;
... ^^^^^^^^
-
Возвращаясь к топику:
недавно еще один товарищ похоже напоролся ровно на тот же трап:
...
x := OPB.NewUnsignedConst( (LONG(y^.conval^.intval) -apar^.conval^.intval) DIV z^.conval^.intval + 1)могло возникнуть переполнение в разности (y^.conval^.intval-apar^.conval^.intval), что искажало результат при последующем делении. Попытка перейти к типу большей разрядности при помощи LONG() вызывало ТРАП 0 (Dev)CPC486 компилятора ББ.
...
Интересно, что попытка соединить в одном операторе и разность и деление
L := (LONG(y^.conval^.intval) -apar^.conval^.intval) DIV z^.conval^.intval +1;
вызывает ТРАП 0 (Dev)CPC486 компилятора ББ! Ну и ладно, не хочет вместе, посчитаем по отдельности.
-
Фикс для исправления этой проблемы (взято в официальной рассылке по BlackBox, автор — luowy). (https://github.com/Oleg-N-Cher/BB-XDev/commit/8b39eb11164460541b56fc096e08e067b90048e5)
P.S. Можно давать ссылки такого рода без sid, это идентификатор сессии.
-
Фикс для исправления этой проблемы (взято в официальной рассылке по BlackBox, автор — luowy). (https://github.com/Oleg-N-Cher/BB-XDev/commit/8b39eb11164460541b56fc096e08e067b90048e5)
Кстати, где-нибудь выложен архив этой рассылки?