OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 03 Март, 2021 14:17

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




Начать новую тему Ответить на тему  [ Сообщений: 64 ]  На страницу Пред.  1, 2, 3, 4
Автор Сообщение
СообщениеДобавлено: Пятница, 04 Декабрь, 2020 18:51 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9370
Откуда: Россия, Орёл
Александр К писал(а):
Если движок форума позволяет, давайте проведём опрос: каким методом будем решать проблему. Лично я за введение LONGCHAR с UTF32. Тот, кто хочет сэкономить память, пусть пользуется существующим CHAR.


Выношу ещё раз вниз решение, которое лично мне кажется оптимальным:
viewtopic.php?p=112613#p112613

Только тогда нужно вводить тип, который гарантированного размера 16бит. Как сейчас фиксирован CHAR. Для тех, кто хочет точного указания. CHAR16, например. А CHAR сделать 32 бит/16 бит от режима компилятора.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Декабрь, 2020 22:58 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 424
Илья Ермаков писал(а):
Но можно принять размерность CHAR решением этапа компиляции.


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

Предлагаю провести анализ ситуаций.

Я полагаю, условно можно разделить программы на А) прикладные и Б) системные.

А) Прикладным программам дела нет до того, какой размерности CHAR. Главное - это (абстрактное) множество всех доступных литер. Значение переменной типа CHAR всегда принадлежит этому множеству. В идеале, если прикладная программа написана грамотно, от изменения представления CHAR вообще не должна зависеть ее работа. Это, кмк, и было надеждой ЯВУ.

Б) Для некоторых системных программ может иметь значение размерность типа CHAR. Причем в двух случаях.
Б1) когда нужно взаимодействовать с внешним беспорядочным миром, который оперирует адресами и буферами вместо литер и строк. (См. LinLibc.printf, например)
Код:
   TYPE LinLibc.PtrSTR* = POINTER TO ARRAY [untagged] OF SHORTCHAR;
   PROCEDURE [ccall] LinLibc.printf* (s: PtrSTR): int;

Б2) когда нужны какие-нибудь фокусы с упаковкой. Например, компилятор, генерируя код, вставляет этот код в ARRAY OF SHORTCHAR; ядро кое-где предоставляет метасведения в виде SHORTCHAR.
Код:
   TYPE DevCPE.CodeBlock = POINTER TO ARRAY CodeLength OF SHORTCHAR;
   PROCEDURE Kernel.GetRefVar (VAR ref: INTEGER; OUT mode, form: SHORTCHAR; OUT desc: Type; OUT adr: INTEGER; OUT name: Utf8Name


Б1, кмк, адекватно можно закрыть с помощью имеющегося SHORTCHAR. Но, будь моя воля, я бы упихал его в SYSTEM - раз уж он нужен для системных программ. Могу тут сослаться в свою поддержку на документ
Programming conventions писал(а):
3 Basic types

Use the types INTEGER, REAL and CHAR as defaults. BYTE, SHORTINT, LONGINT, SHORTREAL and SHORTCHAR should only be used if there is a strong particular reason to justify this choice. The auxiliary types are there mainly for interfacing purposes, for packing of very large structures, or for computation of extremely large integers. This rule is more important for exported interfaces than for hidden implementations, of course.

Эти типы могут создавать иллюзию экономии памяти, однако там, в памяти, все настолько безжалостно выравнивается, что в амд64 при передаче в стек булевых значений КПД составляет 1/64.
Эти типы в прикладных программах заставляют морочить голову с приведением типов. А так, были бы они в SYSTEM - еще трижды подумаешь, прежде чем ими пользоваться.

Б2) Кмк, этот фокус - использование SHORTCHAR Там, где на самом деле нужно беззнаковое целое, а вовсе не литера. Всамделе, и генератор кода ведь генерирует байты, и ядро в метасведениях передает какие-то байты. Как раз байты, в отличие от литер - понятие системного уровня, а не прикладного. И я полагаю, что использование SHORTCHAR здесь - вынужденная мера ввиду отсутствия понятия байтов в языке. Собственно тип BYTE - это не байт, это знаковое целое, которое влезает в 8 бит. В Обероне, емнип, был тип SYSTEM.BYTE - это как раз был беззнаковый байт, просто 8 бит. Его из КП исключили. Но в недрах компилятора он остался: там есть Byte, который соответствует SYSTEM.BYTE, и есть Int8, который соответствует просто BYTE. И правила обращения с ними соответственно беззнаковые и знаковые. Как я понимаю, СР2 компилировал и Оберон-программы (может, и сейчас умеет, если опцию включить).
Поэтому есть и такой вариант:
Language report писал(а):
CHAR the characters of the Unicode character set (MIN(CHAR) .. MAX(CHAR))

Platform-specific issues писал(а):
SYSTEM.BYTE the integers between 0 and 255


а SHORTCHAR... может, в топку его?


Коллеги, какие ситуации следует еще добавить к предложенному анализу?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Декабрь, 2020 23:15 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 424
Я внимательно сейчас перечитал интерфейс (Lin)Kernel, и вот все случаи SHORTCHAR:
Код:
   TYPE
      ItemExt = POINTER TO ABSTRACT RECORD
         (e: ItemExt) GetSStringVal (OUT x: ARRAY OF SHORTCHAR; OUT ok: BOOLEAN), NEW, ABSTRACT;
         (e: ItemExt) PutSStringVal (IN x: ARRAY OF SHORTCHAR; OUT ok: BOOLEAN), NEW, ABSTRACT;
      END;
      Module = POINTER TO RECORD [untagged]
         names-: POINTER TO ARRAY [untagged] OF SHORTCHAR;
      END;

      Utf8Name = ARRAY 256 OF SHORTCHAR;

   PROCEDURE GetRefVar (VAR ref: INTEGER; OUT mode, form: SHORTCHAR; OUT desc: Type; OUT adr: INTEGER; OUT name: Utf8Name);

   PROCEDURE StringToUtf8 (IN in: ARRAY OF CHAR; OUT out: ARRAY OF SHORTCHAR; OUT res: INTEGER);

   PROCEDURE Utf8ToString (IN in: ARRAY OF SHORTCHAR; OUT out: ARRAY OF CHAR; OUT res: INTEGER);


Получается три случая использования SHORTCHAR:
1) в связи со строками в кодировке Utf8
2) в связи со строками в кодировке Latin-1 (то, что в ItemExt)
3) в связи с непойму чем - в процедуре GetRefVar, вполне можно было обойтись без SHORTCHAR

Случай 1) прекрасно поддается изоляции в библиотеку: если откуда-то прилетают или куда-то нужно отослать Утф8 - воспользоваться модулем Utf, а внутри ББ пользоваться CHAR
Случай 2) - ну, вероятно, можно признать его obsolete или outdated. Как я понимаю, в интерфейсах появилось WriteString и WriteSString как переходная мера; кмк, уже можно признать переход завершившимся, не?
Случай 3) мне непонятен; предлагаю его признать огрехом и в амд64 не тащить.

Выходит, даже анализ интерфейса ядра - уж куда системней! - не дает существенных оснований для SHORTCHAR.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Февраль, 2021 15:12 

Зарегистрирован: Воскресенье, 06 Август, 2017 19:33
Сообщения: 62
Цитата:
Получается, чтобы истолковать программу, недостаточно держать в руках программу и определение языка. Необходимо еще знать, с какими опциями предполагается компилировать эту программу. Или с какими она была скомпилирована. Т.е. фактически это две разных программы. Или три? тридцать три? ведь у компилятора может много быть опций.


А что, если сделать какой-нибудь модуль Char, и входе выполнения программы менять разрядность, например так: Char.SetSize (16) или Char.SetSize (32). Это реализовать конечно сложнее, чем статическое указание при компиляции, зато какая свобода появляется.


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

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


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

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


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

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