OSDev

для всех
Текущее время: 17 дек 2017, 20:30

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




Начать новую тему Ответить на тему  [ Сообщений: 19 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 13 мар 2015, 14:06 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
Вот чтоб подобных неувязок не возникало, лично я предпочитаю, чтобы разрядность значения явно указывалась в названии типа -- т.е. Int32, UInt32 и т.п. То же самое касается и вещественных типов -- я б предпочёл Float32, Float64 и т.д.

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 13 мар 2015, 21:40 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
dragon писал(а):
Отлично. Чему будет равен размер word на 8-битном процессоре? На 16-битном процессоре (или в 16-битном режиме x86)? Правильно ли я понимаю, QuadWord на 8-битном процессоре будет 32 бит? Как мне задать тип беззнакового целого размерностью не менее 32 бит?

Наконец-то я понял суть претензий. На данный момент в Канторе немного не так.

Идентификаторы XxxxInt и XxxxWord я рассматриваю как устоявшиеся эвфемизмы типов данных конкретной размерности, поэтому их размерность фиксирована на всех платформах. Можно не согласиться с принципом, предложить свои аргументы, тогда я буду думать. Цифры по-прежнему не хочу. :)

Связь типов с аппаратной платформой также немного отличается от общепринятой. Дело в том, что в Канторе есть только один тип -- class, при наличии параметров он становится обобщением (generic). Все остальные типы определены через классы и обобщения, как если бы в C++ все встроенные типы объявили бы через template <>. Класс в Канторе является функцией, поэтому возможны перегруженные типы, различающиеся набором параметров:
Код:
public class Integer[Word scale]; // обобщение знакового целого типа
public class Word[Word scale]; // обобщение беззнакового целого типа

public class Integer = Integer[registerBits]; // целое размером с регистр, registerBits передается компилятором
public class Word = Word[registerBits]; // беззнаковое целое размером с регистр

Приступая к компиляции, компилятор загружает свою библиотеку и раскрывает обобщения, передавая конкретное значение registerBits, взятое из параметров целевой платформы. Так обеспечивается переносимость.

Я могу разнести обобщенные и конкретные определения по разным идентификаторам, но сути это не изменит:
Код:
public class SignedInteger[Word scale];
public class UnsignedInteger[Word scale];

public class Integer = SignedInteger[registerBits];
public class Word = UnsignedInteger[registerBits];

Разумеется, программист всегда может определить свои типы, -- обобщения-то публичны:
Код:
public class UInt = Word[16];

Классы можно определить даже через частичное применение:
Код:
public class UInt = partial Word;

Данное определение создаст синоним UInt каждому классу Word, сохраняя набор параметров. Хороший пример, почему удобно держать одноименные перегруженные классы.

SII писал(а):
При этом, конечно, потенциально будет страдать переносимость программ (формально всё скомпилируется и запустится, но дальше может работать неправильно -- например, не помещаться в диапазон или терять точность).

А что компилировать-то будет? Само, что ли? Компилятор не надо писать? :lol:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 14 мар 2015, 08:29 

Зарегистрирован: 04 ноя 2007, 14:48
Сообщения: 113
Цитата:
Идентификаторы XxxxInt и XxxxWord я рассматриваю как устоявшиеся эвфемизмы типов данных конкретной размерности, поэтому их размерность фиксирована на всех платформах.


Я правильно понимаю:
SizeOf(ByteInt) = SizeOf(Byte) = 1, на всех платформах;
SizeOf(ShortInt) = SizeOf(ShortWord) = 2, на всех платформах;
SizeOf(LongInt) = SizeOf(LongWord) = 4, на всех платформах;
SizeOf(QuadInt) = SizeOf(QuadWord) = 8, на всех платформах;
причём всё это независимо от размера машинного слова?

Т.е. фактически xxxWord является просто "оборотом речи" и никак не связано с фактическим размером машинного слова?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 14 мар 2015, 13:50 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
Да, именно так. Это можно видеть в пробном Core.can, выложенном еще в прошлом году.

Кстати, операция получения размера памяти для экземпляра записывается в Канторе постфиксным оператором memorysize:
Код:
always1 = Core:Byte memorysize;
always2 = Core:ShortWord memorysize;
always4 = Core:LongWord memorysize;
always8 = Core:QuadWord memorysize;

Такая форма выбрана для единообразия с другими постфиксными операторами, используемыми в выражениях: inner, where, path, root и др. Предполагается, что memorysize придется использовать только как проклятие для передачи в функции системного API, требующие указания размера.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 14 мар 2015, 17:13 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
Freeman писал(а):
SII писал(а):
При этом, конечно, потенциально будет страдать переносимость программ (формально всё скомпилируется и запустится, но дальше может работать неправильно -- например, не помещаться в диапазон или терять точность).

А что компилировать-то будет? Само, что ли? Компилятор не надо писать? :lol:


Не понял сути претензий.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 14 мар 2015, 18:18 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
SII писал(а):
Не понял сути претензий.

Фраза "формально всё скомпилируется и запустится, но дальше может работать неправильно" читается так, будто речь идет о каком-то готовом компиляторе, которым ты пользовался и уже знаешь его поведение. Мы же тут не про Си и не про Аду разговор ведем. Как в Канторе может что-то "формально скомпилироваться", если на какой-то платформе нет инструкций для чисел с плавающей запятой?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 14 мар 2015, 18:45 

Зарегистрирован: 28 окт 2007, 18:33
Сообщения: 1315
Откуда: Зеленоград
Ну, речь-то шла вообще об именовании типов, а не о конкретной реализации конкретного языка на конкретной платформе. Я указал на суть проблемы: даже если для вещественного типа явно указывать его разрядность (например, Float32 или Float64), это не гарантирует 100% переносимости программ на разные архитектуры. Дело не в (не)возможности создания компилятора, а в том, что одинаковые по разрядности вещественные типы могут различаться своим "внутренним устройством", а значит, обеспечивать неодинаковый диапазон и точность представления данных -- что и может привести к проблемам с переносимости конкретных программ.

Скажем, у мэйнфреймов IBM "классические" инструкции вещественной арифметики трактуют числа не как двоичные, а как шестнадцатеричные -- порядок у них является степенью числа 16, а мантисса состоит из шестнадцатеричных, а не двоичных цифр, почему в ней нет скрытого старшего разряда. По этой причине диапазон представимых чисел при той же разрядности типа (32 или 64 бита) у мэйнфреймов больше (степень 16, а не 2), а вот точность в общем случае меньше (в мантиссе присутствует до 4 ведущих нулей, если трактовать её как двоичную), чем у вещественных чисел стандарта IEEE 754.

Ну а что конкретно Кантор почему-то должен прерывать компиляцию, обнаружив, что аппаратной поддержки вещественной арифметики нет... Это, конечно, право разработчиков компилятора, но, как по мне, это дурной подход. Какая проблема программно реализовать необходимую поддержку? А может, в этом языке стоит отказаться ещё и от целочисленного деления? В подавляющем большинстве ARMов соответствующей инструкции нет -- делить приходится подпрограммой. Ну или заведомо отказаться от реализации языка на любых платформах, где хоть чего-то аппаратного не хватает?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 15 мар 2015, 00:18 
Аватара пользователя

Зарегистрирован: 28 май 2012, 23:44
Сообщения: 237
Откуда: Санкт-Петербург
SII писал(а):
Какая проблема программно реализовать необходимую поддержку? А может, в этом языке стоит отказаться ещё и от целочисленного деления? В подавляющем большинстве ARMов соответствующей инструкции нет -- делить приходится подпрограммой.

Никакой проблемы в программной реализации нет. До ARM еще дожить нужно. Не в первой версии.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Real или Float?
СообщениеДобавлено: 31 июл 2016, 18:10 

Зарегистрирован: 31 июл 2016, 05:47
Сообщения: 2
В FORTRAN до сих пор REAL.
Для совместимости с кодом, накопленным за полувековую историю, есть ещё DOUBLE PRESISION. Но он настройками компилятора или ещё как-нибудь настраивается на какой-нибудь REAL(KIND( 0D0))

https://gcc.gnu.org/onlinedocs/gcc-5.1. ... L_005fKIND


4.4.2.3 Real type4

1 The real type has values that approximate the mathematical real numbers. The processor shall provide two or more approximation methods that define sets of values for data of type real. Each such method has a representation method and is characterized by a value for the kind type parameter KIND. The kind type parameter of an approximation method is returned by the intrinsic function KIND (13.7.89)

2 The decimal precision, decimal exponent range, and radix of an approximation method are returned by the intrinsic functions PRECISION (13.7.131), RADIX (13.7.134) and RANGE (13.7.137). The intrinsic function SELECTED REAL KIND (13.7.147) returns a kind value based on specified precision, range, and radix requirements.

NOTE 4.7 See C.1.1 for remarks concerning selection of approximation methods.


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

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


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

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


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB