OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 26 Сентябрь, 2018 12:41

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 78 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Воскресенье, 06 Ноябрь, 2011 17:59 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Видимо, имелось в виду, что INTEGER знаковый. Но это не имеет значения - арифметика знаковая и беззнаковая идентично работает (за счёт дополнительного кода).

Но в Винде всё равно 2Гб. В адресном пространстве процессов именно такой интервал доступен приложениям. Остальные адреса зарезервированы для ОС, для проецированных в пространство процесса её библиотек и проч. Правда, есть ключик какой-то в boot.ini, чтобы ОС давала 3Гб.
В Линуксе не знаю. Тем более в Wine.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Воскресенье, 06 Ноябрь, 2011 18:10 

Зарегистрирован: Среда, 04 Июль, 2007 16:43
Сообщения: 231
Вот тут memory allocation limit for a 32-bit app on a 64-bit system написано, что увеличение предела до 4 ГБ все-таки возможно и для 32-битных приложений. Может все не так уж и безнадежно?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Воскресенье, 06 Ноябрь, 2011 18:23 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Может быть. Мои суждения старые, ещё из эпохи Win2k :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 07 Ноябрь, 2011 11:57 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Кстати, поверхностно просматривая функции WinAPI я что-то не увидел процедурки выделяющей блоки памяти размером больше чем указывается 32-разрядным числовым аргументом. По моему, в 64 разрядном API логично было бы добавить процедурку в которой размер блока задавался бы 64-разрядным числовым параметром. Но такой процедуры почему-то нет. То есть, получается, что даже под 64 разрядной виндой, хоть и можно получить много памяти, но непрерывные её куски всё равно будут ограничены размером 2 (4?) Гб.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 07 Ноябрь, 2011 13:37 

Зарегистрирован: Понедельник, 28 Ноябрь, 2005 10:28
Сообщения: 1086
Под win64 SIZE_T 64-разрядный.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 23 Апрель, 2013 19:55 

Зарегистрирован: Среда, 04 Август, 2010 04:01
Сообщения: 37
Откуда: Сан Хосе, Калифорния, США
Info21 писал(а):
Целые, как и SET, ни в коем случае нельзя трогать.
Ни по-хорошему, никак.
Они были зафиксированы для переносимости, и это должно быть сохранено.

Если нужно 128 бит -- это HUGEINT.


Типы Integer, Real, Set - это машинное приближение математическмз абстракций. Основно требование к ним - быть максимально приближенными к исходным математическим понятиям. Соответственно, чем выше разрядность, тем ближе эти типы к своим прототипам и ниже вероятность ошибки переполнения при математических расчетах. Поэтому, я считвю что INTEGER, REAL и SET должны использовать максимально возможную для выбранной платформыв разрядность и обеспечивать максимальную точность. Тем самым будет обеспечена переносимость исходного кода написанного для научных и инженерных расчетов и будет гарантия, что точность расчетов при переносе не пострадает.
Другие типы - SHORTINT, LONGINT, DOUBLE - просто попытка учесть некоторые платформенные особенностии по сути являются низкоуровневыми средствами. По мне, так я бы просто вынес их в SYSTEM и заменил явным указанием разрядности: INT8,INT16,INT32,INT64, Точно так же можно было бы в SYSTEM ввести SET8, SET16,SET32 для побитных операций с регистрами, портами и т.п. Использование этих типов нужно в основном для работы с железом и использования особенностей платформы для оптимизации памяти и операций.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Вторник, 23 Апрель, 2013 20:32 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7850
Откуда: Троицк, Москва
nail_kh писал(а):
Info21 писал(а):
Целые, как и SET, ни в коем случае нельзя трогать.
Ни по-хорошему, никак.
Они были зафиксированы для переносимости, и это должно быть сохранено.

Если нужно 128 бит -- это HUGEINT.


Типы Integer, Real, Set - это машинное приближение математическмз абстракций. Основно требование к ним - быть максимально приближенными к исходным математическим понятиям.
Нет, это не основное требование к ним.

Это инструмент реализации разных моделей математических понятий.
То, что для простых случаев модель в 1:1 совпадает с инструментом реализации -- это, скорее, счастливый случай.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Воскресенье, 30 Июнь, 2013 10:27 

Зарегистрирован: Среда, 04 Август, 2010 04:01
Сообщения: 37
Откуда: Сан Хосе, Калифорния, США
Info21 писал(а):
nail_kh писал(а):
Info21 писал(а):
Целые, как и SET, ни в коем случае нельзя трогать.
Ни по-хорошему, никак.
Они были зафиксированы для переносимости, и это должно быть сохранено.

Если нужно 128 бит -- это HUGEINT.


Типы Integer, Real, Set - это машинное приближение математическмз абстракций. Основно требование к ним - быть максимально приближенными к исходным математическим понятиям.
Нет, это не основное требование к ним.

Это инструмент реализации разных моделей математических понятий.
То, что для простых случаев модель в 1:1 совпадает с инструментом реализации -- это, скорее, счастливый случай.


Позволю себе не согласиться с Вами. Если я как инженер решаю сложную математическую задачу на компьютере с использованием целых, вещественных чмсел и множеств, то мне не важно, как реализованы эти понятия в компьютере. Меня интересует только диапазон целых, точность представления и диапазон вещественных и максимально допустимое количнство элементов в множестве. Я просто хочу быть уверенным, что при расчетаъ удастся избежать переполнения при операциях с целыми, уменьшить ошибки округления при операциях с вещественными и быть уверенным в том, что могу включить в множетсво пару- другую дополнительных элементов.
При этом, если 32 двух разрадное целое и множество начинают ограничивать меня в расчетах, то хотелось бы иметь возможность просто перенести код на 64 или 128 разрядную платформу, не грея голову, что использовать, integer или int64, real или double (а может triple или quadruple?). Поэтому на мой взгляд integer, real и set должны реализоваться с масимальной разрядностью, которую без потери скорости позволяет иметь выбранная платформа.
Только в этом случае можно обеспечить совместимость снизу вверх.
Что касается всяких int8, int16, longint, byte, word, single, double, т.д. - то эти типы суть отражение конкретной архитектуры. С таким же успехом могли бы быть и int24, int48, triple (вместо double). Они нужны когда речь идет об управлении конкретным железом а не о высокоуровневых задачах.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Воскресенье, 30 Июнь, 2013 11:01 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
nail_kh писал(а):
Что касается всяких int8, int16, longint, byte, word, single, double, т.д. - то эти типы суть отражение конкретной архитектуры. С таким же успехом могли бы быть и int24, int48, triple (вместо double). Они нужны когда речь идет об управлении конкретным железом а не о высокоуровневых задачах.


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

Тот же INTEGER - Вы использовали как "просто целое", а кто-то - как 32-бит целое. И имел он на это полное право, потому что диапазоны для типов зафиксированы в стандарте языка (приложение C), как это было сделано и в Java.
Разумность такой фиксации была, потому что с переходом к 32-бит архитектурам ситуация, как мы выше в этой ветке обсудили, радикально изменилась: если раньше ёмкости было практически всегда "мало", то с 32-бит произошло насыщение: для большинства применений сразу стало "нормально". Поэтому разумно было перейти от плавающей разрядности типов к фиксированной.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Воскресенье, 30 Июнь, 2013 16:33 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 7850
Откуда: Троицк, Москва
Нечего добавить к тому, что написал Илья Евгеньевич. Спасибо ему :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 08:06 

Зарегистрирован: Среда, 04 Август, 2010 04:01
Сообщения: 37
Откуда: Сан Хосе, Калифорния, США
Илья Ермаков писал(а):
Тот же INTEGER - Вы использовали как "просто целое", а кто-то - как 32-бит целое. И имел он на это полное право, потому что диапазоны для типов зафиксированы в стандарте языка (приложение C), как это было сделано и в Java.
Разумность такой фиксации была, потому что с переходом к 32-бит архитектурам ситуация, как мы выше в этой ветке обсудили, радикально изменилась: если раньше ёмкости было практически всегда "мало", то с 32-бит произошло насыщение: для большинства применений сразу стало "нормально". Поэтому разумно было перейти от плавающей разрядности типов к фиксированной.

Как раз сейчас на работе расхлебываю результвт зафиксированной длины типа int в С++ и возникших с этим ограничений
Еще лет 10 назад те же видео-сенсоры имели разрешение 1-3 мегапиксел и 32 разрядного int для целочисленных алгоритмов обработки данных вполне хватало. Сейчас пошли 12-18 мегапикселов с 11-12 разрядными данными. Нетрудно посчитать, что даже простое суммрование сигналов при подсчете среднего с 10 мегабитного сенсора с 11 битным сигналом пиксела может привести к переполнению: 10000000*2048=20400000000 > 2147483647= фиксированный верхний предел int в C++ .
В результате имеем парадоксальную ситуацию: есть компъютер с 64 разрядной арифметикой, есть компилятор С++, но простое увеличение диапазона входных данных вынуждает пересмотреть исходный код и заменить все int на _int64. От Блекбокса, даже если будет версия под 64 бита, но разрядность INTEGER и REAL в нем останутся прежними, тоже толку будет мало, ибо все равно придется пересматривать исходный код и менять INTEGER на новый, пока еще до конца не определенный тип.
Аналогичные проблемы возникают с типом REAL. Ошибки растут с увеличением объема исходных данных. В условиях производства самым простым решением является переход с 32-разрядной платформы на 64 разрядную. Не хотелось бы при этом еще и пересматривать исходники.
Так что о "насыщении" при решении серьезных задач пока говорить не приходится.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 08:38 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2178
Откуда: Нижний Новгород
nail_kh писал(а):
Илья Ермаков писал(а):
Тот же INTEGER - Вы использовали как "просто целое", а кто-то - как 32-бит целое. И имел он на это полное право, потому что диапазоны для типов зафиксированы в стандарте языка (приложение C), как это было сделано и в Java.
Разумность такой фиксации была, потому что с переходом к 32-бит архитектурам ситуация, как мы выше в этой ветке обсудили, радикально изменилась: если раньше ёмкости было практически всегда "мало", то с 32-бит произошло насыщение: для большинства применений сразу стало "нормально". Поэтому разумно было перейти от плавающей разрядности типов к фиксированной.

Как раз сейчас на работе расхлебываю результвт зафиксированной длины типа int в С++ и возникших с этим ограничений
...
В результате имеем парадоксальную ситуацию: есть компъютер с 64 разрядной арифметикой, есть компилятор С++, но простое увеличение диапазона входных данных вынуждает пересмотреть исходный код и заменить все int на _int64.


Это просто не правда. Вы не знаете С++. int, long и так далее в С++ не имеют фиксированой длины. На разных платформах, разных компиляторах она будет разная. Где-то int будет 8 бит, где-то 16, где-то 32, а где-то 64. Маленькая выдержка из стандарта:
Цитата:
Certain aspects and operations of the abstract machine are described in this International Standard as
implementation-defined (for example, sizeof(int)). These constitute the parameters of the abstract machine. Each implementation shall include documentation describing its characteristics and behavior in these
respects.


И вот эта вот нефиксированная сущность int'а всегда была большой проблемой в C++98 и С89/90 (недавно как раз разгребал код на С89 с ошибкой из за оной нефиксированной сущности int'а, и ровно то же самое было бы будь этот код писан на Обероне или Обероне-2, а на КП проблемы такой не было бы). К счастью вышел в 99 году С99, а теперь и С++11 (новый стандарт), где определен заголовочный файл stdint.h, где определены в свою очередь целочисленные типы с определенными гарантиями по ёмкости, и это здорово.

Ваша же проблема в том, что вы элементарно неправильно написали приложение. Вместо того, чтобы сделать typedef uint32_t integral_int_t, и в последствии именно им (integral_int_t - да, задача по формированию integral image мне знакома) пользоваться везде для обработки изображений, вы напрямую везде использовали сырой тип int, который не дает каких-либо гарантий по ёмкости. Соответственно вы лишились возможности при изменении условий (большие изображения) одной строчкой гарантированно изменить ёмкость целочисленного типа в нужных местах.

PS. А типа _int64 в С++ и Си нет. Вообще. Похоже вы пишете на на С++, а на "языке" VisualC++.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 08:41 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
nail_kh писал(а):
Как раз сейчас на работе расхлебываю результвт зафиксированной длины типа int в С++ и возникших с этим ограничений


Ну так это не проблема типов, а проблема того, кто писал то ПО.
Если алгоритмическая часть там действительно могла быть универсальной (не привязанной к конкретной разрядности сигнала), то кто мешал использовать typedef?? Определить какой-либо тип, допустим, typedef int SensorSample - и дальше в коде использовать его.
То же самое на Обероне - TYPE Sensor = INTEGER.
И потом переопределить в одном месте.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 08:51 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2178
Откуда: Нижний Новгород
Илья Ермаков писал(а):
nail_kh писал(а):
Как раз сейчас на работе расхлебываю результвт зафиксированной длины типа int в С++ и возникших с этим ограничений


Ну так это не проблема типов, а проблема того, кто писал то ПО.
Если алгоритмическая часть там действительно могла быть универсальной (не привязанной к конкретной разрядности сигнала), то кто мешал использовать typedef?? Определить какой-либо тип, допустим, typedef int SensorSample - и дальше в коде использовать его.
То же самое на Обероне - TYPE Sensor = INTEGER.
И потом переопределить в одном месте.

Маленькое примечание - в современном Обероне (Oberon-07/11) - это невозможно. Там нельзя заводить алиасы для не структурных типов.

А вообще, проблема в том, что ни INTEGER в Обероне (не путать с КП!) ни int в с++ не дает каких-либо гарантий по минимальной разрядности. Полагаю их алгоритм не стал бы работать если б int/INTEGER внезапно оказался бы 8ми битным. Поэтому, если мы говорим о Обероне, то в стандартной (то есть за которую отвечает создатель конкретного компилятора) библиотеке должен быть модуль аналогичный сишному stdint.h.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 10:25 

Зарегистрирован: Среда, 04 Август, 2010 04:01
Сообщения: 37
Откуда: Сан Хосе, Калифорния, США
Alexey Veselovsky писал(а):
Это просто не правда. Вы не знаете С++. int, long и так далее в С++ не имеют фиксированой длины. На разных платформах, разных компиляторах она будет разная. Где-то int будет 8 бит, где-то 16, где-то 32, а где-то 64.
.


Честно говоря, не ожидал столь бурной реакции на высказанное мнение, да еще с переходом от обсуждения концепции языка к обсуждению моих навыков.
Ну да ладно.
За все платформы говорить не стану. Сошлюсь на это: http://msdn.microsoft.com/en-us/library/296az74e.aspx
INT_MAXMaximum value for a variable of type int. 2147483647
Насчет обвинения в незнании С++ - оправдываться не буду. Сразу признаюсь. Не гуру. Никогда не любил С /С++ и програмирую на них по необходимости.
предпочитаю Blackbox. Так что, коллеги, не стоит отвлекаться на обсуждение моей персоны. Она того не заслуживает )))

Alexey Veselovsky писал(а):
Ваша же проблема в том, что вы элементарно неправильно написали приложение. Вместо того, чтобы сделать typedef uint32_t integral_int_t, и в последствии именно им (integral_int_t - да, задача по формированию integral image мне знакома) пользоваться везде для обработки изображений, вы напрямую везде использовали сырой тип int, который не дает каких-либо гарантий по ёмкости. Соответственно вы лишились возможности при изменении условий (большие изображения) одной строчкой гарантированно изменить ёмкость целочисленного типа в нужных местах.

Насчет "чтобы сделать typedef uint32_t integral_int_t," - увы, мои предшественники. с чьими кодоми я сейчас разбираюсь, предусмотреть все что могло случиться через несколько лет вряд ли могли. Работали с тем, что есть.

Насчет "сырого типа int". На мой взгляд типы INTEGER и REAL в языки программирования были введены задолго до появления Оберона,начиная с Фортрана и Алгола и присутствуют практически во всех компилируемых языках. И в большинстве расчетных задач главное для INTEGER - диапазон, а для REAL - диапазон и количество знаков в мантиссе. И чем они больше, тем меньше вероятность переполнения и ошибок округления. И если алгорит работал без переполненийи и приемлемымыи ошибками округления на 16 битной платформе, то уж тем более он работал на 32х битной.
С этой точки зрения уж коли INTEGER и REAL в процессе развития эволюционировали с 8 битных до 32 битных, то зачем же пресекать этот процесс зафиксировав INTEGER на 32 бит? Пусть и дальше расширяются до 64х, 128 и т.д. Не вижу в этом ничего плохого.
Ну а для типов с фиксированной разрядностью ,(IMHO) лучше было бы иметь названия, которые однозначно определяют их реализацию: BIT, BYTE, WORD, INT16, IN32 и т.д.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 10:39 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2178
Откуда: Нижний Новгород
nail_kh писал(а):
Alexey Veselovsky писал(а):
Это просто не правда. Вы не знаете С++. int, long и так далее в С++ не имеют фиксированой длины. На разных платформах, разных компиляторах она будет разная. Где-то int будет 8 бит, где-то 16, где-то 32, а где-то 64.
.


Честно говоря, не ожидал столь бурной реакции на высказанное мнение, да еще с переходом от обсуждения концепции языка к обсуждению моих навыков.
Ну да ладно.
За все платформы говорить не стану. Сошлюсь на это: http://msdn.microsoft.com/en-us/library/296az74e.aspx
INT_MAXMaximum value for a variable of type int. 2147483647

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

nail_kh писал(а):
Насчет "чтобы сделать typedef uint32_t integral_int_t," - увы, мои предшественники. с чьими кодоми я сейчас разбираюсь, предусмотреть все что могло случиться через несколько лет вряд ли могли. Работали с тем, что есть.

Конечно же могли. Тут достаточно знать язык на котором пишешь и иметь элементарную культуру работы с типами (это важнейший механизм построения абстракций, что позволяет в итоге избежать массы проблем).

nail_kh писал(а):
С этой точки зрения уж коли INTEGER и REAL в процессе развития эволюционировали с 8 битных до 32 битных, то зачем же пресекать этот процесс зафиксировав INTEGER на 32 бит? Пусть и дальше расширяются до 64х, 128 и т.д. Не вижу в этом ничего плохого.
Ну а для типов с фиксированной разрядностью ,(IMHO) лучше было бы иметь названия, которые однозначно определяют их реализацию: BIT, BYTE, WORD, INT16, IN32 и т.д.

Штука в том, что приложение и алгоритмы частенько переносятся не только с платформы с меньшей битностью на платформу с большей, но и наоборот. Предположить, что битность при развитии приложения будет монотонно возрастать - означает допустить крупную стратегическую ошибку. Мне например совсем недавно приходилось переносить код с 64бит на 16бит. И если бы у меня там был бы такой вот "безразмерный" int - было бы тяжко.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 10:46 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
nail_kh писал(а):
Насчет "сырого типа int". На мой взгляд типы INTEGER и REAL в языки программирования были введены задолго до появления Оберона,начиная с Фортрана и Алгола и присутствуют практически во всех компилируемых языках. И в большинстве расчетных задач главное для INTEGER - диапазон

Да, но это только для расчётных!

Цитата:
И если алгорит работал без переполненийи и приемлемымыи ошибками округления на 16 битной платформе, то уж тем более он работал на 32х битной.

А если алгоритм использовал работу с битами, масками, побитовые сдвиги, MOD, наконец? Где гарантия, что там нет привязки к текущей битности - и что достаточно просто перекомпилировать?

Цитата:
С этой точки зрения уж коли INTEGER и REAL в процессе развития эволюционировали с 8 битных до 32 битных, то зачем же пресекать этот процесс зафиксировав INTEGER на 32 бит? Пусть и дальше расширяются до 64х, 128 и т.д. Не вижу в этом ничего плохого.

Дело в том, что процесс эволюции не был безболезненным...
Переход с 16 бит на 32 бит дал столько проблем и привёл практически к переписыванию с нуля многого софта. В частности, из-за смены модели памяти, адресации (от сегментной к плоской модели памяти, когда указатель стал просто 32-бит числом в рамках сплошного виртуального пространства).
Разумеется, проблем с переходом было столько, что на фоне полного переписывания софта какая-то там смена разрядности целого сама по себе была частностью...
Теперь же при переходе на 64 бит никакой революции не происходит. Та же модель памяти. Системщикам переписывать ничего заново не хотелось бы. И, в частности, именно чтобы не иметь тонких неявных проблем в системном коде, связанном с работой с памятью, нежелательно уплывание стандартных типов.

Вообще, переход на 64 бит целесообразно рассматривать как появление некоей надстройки. Работа с LONGINT-ом становится быстрее. Должен появится новый тип для 128-бит арифметики. Можно использовать больше памяти (теперь фактически "сколько угодно", ибо 2^64 не вычерпается физически чисто никак...).
Т.е. те, кто работал на пределе возможностей, получат новое "вооружение". Все остальные не должны ничего вообще заметить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 10:50 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 8989
Откуда: Россия, Орёл
Илья Ермаков писал(а):
И, в частности, именно чтобы не иметь тонких неявных проблем в системном коде, связанном с работой с памятью, нежелательно уплывание стандартных типов.


Т.е., разумеется, если переходим к 64-бит адресации, то трогать этот код придётся. Вот и нужно, чтобы можно было его переводить на новый тип данных, сразу видя, какой код сидит на INTEGET и корректно работает только в пределах 2Гб памяти, а какой перевён уже на 64 бит.
Иначе получится путаница.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 11:20 

Зарегистрирован: Среда, 04 Август, 2010 04:01
Сообщения: 37
Откуда: Сан Хосе, Калифорния, США
Илья Ермаков писал(а):
nail_kh писал(а):
Насчет "сырого типа int". На мой взгляд типы INTEGER и REAL в языки программирования были введены задолго до появления Оберона,начиная с Фортрана и Алгола и присутствуют практически во всех компилируемых языках. И в большинстве расчетных задач главное для INTEGER - диапазон

Да, но это только для расчётных!

Цитата:
И если алгорит работал без переполненийи и приемлемымыи ошибками округления на 16 битной платформе, то уж тем более он работал на 32х битной.

А если алгоритм использовал работу с битами, масками, побитовые сдвиги, MOD, наконец? Где гарантия, что там нет привязки к текущей битности - и что достаточно просто перекомпилировать?



Ну так давайте оставим универсальные типы INTEGER и REAL для расчетов, а для работы с битами, масками, сдвигами и т.д. - будем использовать типы с названиями, явно отражающими их разрядность. Если более высокоразрядная платформа поддерживает эти явные типы (а это почти всегда так), то никаких проблем с компиляцией быть не должно. Разумеется, это не относится к случаю, когда программист использует INTEGER (или что вообще немыслимо - REAL) для битовых операций, а BYTE и CHAR - для расчетов. Тут, как говорится, против лома нет приема.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox 64
СообщениеДобавлено: Понедельник, 01 Июль, 2013 11:22 

Зарегистрирован: Вторник, 25 Апрель, 2006 16:21
Сообщения: 2178
Откуда: Нижний Новгород
nail_kh писал(а):
Ну так давайте оставим универсальные типы INTEGER и REAL для расчетов, а для работы с битами, масками, сдвигами и т.д. - будем использовать типы с названиями, явно отражающими их разрядность. Если более высокоразрядная платформа поддерживает эти явные типы (а это почти всегда так), то никаких проблем с компиляцией быть не должно. Разумеется, это не относится к случаю, когда программист использует INTEGER (или что вообще немыслимо - REAL) для битовых операций, а BYTE и CHAR - для расчетов. Тут, как говорится, против лома нет приема.

Как я описал выше, для расчетов "универсальные" (то есть без каких-либо гарантий) типы INTEGER и REAL также не годятся.

В этом плане лучше всего конечно сделано в Аде.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 78 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2018, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB