Иногда я думаю, почему так прагматично названы единицы пакетов информации?
8 бит - byte;
16 бит - word;
32 бита - dword...
Для своих внутренних проектов я давно использую такие идентификаторы:
| bits | id | Description |
|---|---|---|
| 8 | char | символ (буква) |
| 16 | slab | слог (слог) |
| 32 | word | слово (глагол) |
| 64 | note | запись (письмо) |
| 128 | list | список |
| 256 | page | страница (лист) |
| 512 | heap | стопка |
| 1024 | knot | связка |
| 2048 | tail | повесть |
| 4096 | book | книга (книга) |
| 8192 | file | файл |
| 16384 | посылка | |
| 32768 | room | комната |
| 65536 | dale | долина |
Иногда я сильно сожалею, что не родился в период рассвета информационных технологий, чтобы так или иначе повлиять на них на корню...
У всех программ есть области собственных служебных ячеек памяти.
Так, в ZX-Spectrum'е встроенный интерпретатор Basic (а по сути, сама т.н. BIOS) имел 182 служебные ячейки по адресам 0x5C00..0x5CB5, которые можно было настраивать самому в особых случаях.
Я воспитывался всё же в духе того времени и ко мне приходило несколько интересных идей в ту пору.
Например, использовать часть бордюра экрана (а в ZX-Spectrum он был достаточно толстым) для вывода служебной информации на аппаратном уровне. Скажем, если Вы - взломщик компьютерных игр, можно было бы в схему генератора растра врезать специальный отладочный девайс с собственным генератором символов и заполнить часть бордюра полезной информацией прямо на аппаратном уровне. А именно...
Отобразить дамп служебных ячеек. Диапазон адресов, по которым процессор часто обращается. Список портов, с которыми процессор имеет дело. И т.п...
Со временем я задумался, а почему разработчики вычислительных систем вообще не предусмотрели такие возможности с самого начала? Почему не существует возможного протокола визуализации состояния активного процесса?
Вот скажем, загрузчик DOS в своё время достаточно долго грузил в память всю систему с 5"25 дискет. Иногда со скрежетом пересчитывая вновь некоторые треки.
Можно было бы условиться, что в пространстве будет распологаться регион служебных кросс-ячеек текущего процесса. Куда загрузчик мог бы писать некоторую информацию о своём состоянии (индекс текущего трека, сколько Кб всего прочитано, сколько ошибок зафиксированно и т.д.).
Не важно, чем эти ячейки можно было просмотреть. Главное, чтобы было жёсткое правило, которое бы гласило, что любой процесс обязан за переиод своей работы изменить хотя бы одну кросс-ячейку.
Для чего это надо?
Многие службы и демоны обычно не имеют никакого отображаемого интерфейса, тихо работая в фоне. Это можно сказать и о серверах Apache, MySQL и т.д. Следуя идеологии UNIX "Если писать нечего, не выводи ничего.".
Теоретически, раскол между программами, использующими графический интерфейс и демонами можно было бы изначально устранить, избежав глубокую пропасть.
Т.е. если мы хотим узнать, что в данный момент делает тот или иной процесс, достаточно было бы прочесть его "публичные" ячейки статуса.
Грубо говоря, даже выделив скупую страничку 4Кб, в неё можно поместить кучу различной информации. Например:
0x0000..0x00FF: Общая информация о процессе: Имя процесса; Тип интерфейса; Версия интерфейса и т.п.
0x0100..0x01FF: Область символов. До 2048 chekbox'ов; До 65536 radiobutton'ов и т.п.
0x0200..0x03FF: Область коротких. До 256 spinner'ов, scrollbar'ов, trackbar'ов, combobox'ов, progressbar'ов и т.п.
0x0400..0x07FF: Область целых. До 8192 checkbox-флажков и т.п.
0x0800..0x0FFF: Область длинных. До 256 floats, строки ascii/unicode.
В этом случае все 4Кб похожи на подобие коммутаторной площадки, которые отдельными проводками можно привязать к своим тумблерам и индикаторам.
Тем самым, любой процесс в свободное время мог бы пассивно выдавать любую информации о ходе своих вычислений и управляться извне в узких местах во время отладки/калибровки.
DIM: Data Interaction Map
-------------------------
0000..000F%??:AREA<Dump Release>
0010..001F%??:BOOT<Dump Version>
0020..003F%04:CURE<Dump Correct>
0040..007F%??:DUMP<Dump Setting>
0080..00FF%??:EVAL<Dump Propose>
0100..01FF%01: BYTE/CHAR
0200..03FF%02: WORD/SHORT
0400..07FF%04: DWORD/LONG
0800..0FFF%08: QWORD/HYPER
1000..1FFF%16: DQWORD/
2000..3FFF%32:
4000..7FFF%64: TCHAR[64]
8000..FFFF%??: <Squirrel>
000000000000xxxx.area: char[16]
000000000001xxxx.boot: char[16]
00000000001xxxxx.cure: long[8] ; CRC32
0000000001xxxxxx.dump: char[64]
000000001xxxxxxx.eval: ...[128]
00000001xxxxxxxx.char: BYTE/CHAR
0000001xxxxxxxx0.slab: WORD/SHORT
000001xxxxxxxx00.word: DWORD/LONG
00001xxxxxxxx000.note: QWORD/HYPER
0001xxxxxxxx0000.list:DQWORD/XMM
001xxxxxxxx00000.page:TCHAR[32]
01xxxxxx00000000.icon:ICONS[16x16]
1xxxxxxxxxxxxxxx.text:<Squirrel>
.0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F
0000
0080 XX-XX-XX-XX .. .. XX-XX .. .. XX-XX .. XX .. XX
01x0 XX .. XX .. XX .. XX .. XX .. XX .. XX .. XX ..
02x0 XX-XX .. .. XX-XX .. .. XX-XX .. .. XX-XX .. ..
04x0 XX-XX-XX-XX .. .. .. .. XX-XX-XX-XX .. .. .. ..
08x0 XX-XX-XX-XX-XX-XX-XX-XX .. .. .. .. .. .. .. ..
1xx0 XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX-XX
2xx0 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
4x00 .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
area: Формальная область заголовка/версии карты дампа
boot: Формальная область заголовка рендеринга данных дампа
dump: Служебная область интерактивного командного реактора
eval: Служебная область интерактивного визуального реактора
cure
::::
cure[7] - crc of char[0..255]
cure[6] - crc of slab[0..255]
cure[5] - crc of word[0..255]
cure[4] - crc of note[0..255]
cure[3] - crc of list[0..255]
cure[2] - crc of page[0..255]Vector__Mask 00000xxxxxxx char[128] // Header 00001xxxxxxx char[128] // Option Files Dump 0001xxxxxxxx char[256] // Char's Table 001xxxxxxxx0 short[256] // Short's Table 01xxxxxxxx00 long[256] // Long's Table 1xxxxxxxx000 hyper[256] // Hyper's Table
// gab: gui aid bus
#define GAB_DUMPER ("*GUI AID BUS*\t\t\t"\
"Version 1-alpha\r"\
"Identification: ")
#define GAB_VIEWER ("Transformation: ")
typedef struct {
struct { // addr .0 .1 .2 .3 .4 .5 .6 .7 .8 .9 .A .B .C .D .E .F ________________
char sDumper[48]; // +000 2A 47 55 49 20 41 49 44 20 42 55 53 20 09 09 09 *GUI AID BUS*→→→
// +010 56 65 72 73 69 6F 6E 20 31 2D 61 6C 70 68 61 0D Version 1-alpha↵
// +020 49 64 65 6E 74 69 66 69 63 61 74 69 6F 6E 3A 20 Identification:
char sDumpId[32]; // +030 ............................................... ________________
// +040 ............................................ 0D _______________↵
char sViewer[16]; // +050 54 72 61 6E 73 66 6F 72 6D 61 74 69 6F 6E 3A 20 Transformation:
char sViewId[32]; // +060 ............................................... ________________
// +070 ............................................ 0D _______________↵
char cFileA[48]; // +080 ............................................... ________________
// +090 ............................................... ________________
// +0A0 ............................................... ________________
char cDumpA[16]; // +0B0 ............................................... ________________
char cFileB[48]; // +0C0 ............................................... ________________
// +0D0 ............................................... ________________
// +0E0 ............................................... ________________
char cDumpB[16]; // +0F0 ............................................... ________________
union {
char sbPar[256]; // Signed Byte Parameter
BYTE ubPar[256]; // Unsigned Byte Parameter
};
union {
short swPar[256]; // Signed Word Parameter
WORD uwPar[256]; // Unsigned Word Parameter
};
union {
long sdPar[256]; // Signed DWord Parameter
DWORD udPar[256]; // Unsigned DWord Parameter
};
union {
hyper sqPar[256]; // Signed QWord Parameter
QWORD uqPar[256]; // Unsigned QWord Parameter
};
};
} GAB, *PGAB;Исходный файл экспериментального дампа кросс-интерфейса.
(Используется RIFF древо, редактируемое в VirtualDub-Hex редакторе.)
<?xml version="1.0" encoding="utf-8"?><!-- comment #1 -->
<access-policy>
<cross-domain-access>
<policy>
<allow-from>
<domain uri="file:///" /><!-- comment #2 -->
</allow-from>
<grant-to>
<socket-resource port="4502-4506" protocol="tcp" />
</grant-to>
</policy>
</cross-domain-access>
</access-policy>xml comment #1
.version="1.0"
.encoding="utf-8"
access-policy
cross-domain-access
policy
allow-from
domain
.url="file:///" comment #2
grant-to
socket-resource
.port="4502-4506"
.protocol="tcp"Wiki-<a href='http://ru.wikipedia.org/wiki/XML#.D0.AD.D0.BB.D0.B5.D0.BC.D0.B5.D… 2.D0.B5.D0.B3.'>Источник</a>:
<recipe name="хлеб" preptime="5" cooktime="180">
<title>Простой хлеб</title>
<composition>
<ingredient amount="3" unit="стакан">Мука</ingredient>
<ingredient amount="0.25" unit="грамм">Дрожжи</ingredient>
<ingredient amount="1.5" unit="стакан">Тёплая вода</ingredient>
<ingredient amount="1" unit="чайная ложка">Соль</ingredient>
</composition>
<instructions>
<step>Смешать все ингредиенты и тщательно замесить.</step>
<step>Закрыть тканью и оставить на один час в тёплом помещении.</step>
<!-- <step>Почитать вчерашнюю газету.</step> - это сомнительный шаг... -->
<step>Замесить ещё раз, положить на противень и поставить в духовку.</step>
</instructions>
</recipe>Возможное Lite-представление:
recipe
.name="хлеб"
.preptime="5"
.cooktime="180"
title
"Простой хлеб"
composition
ingredient
.amount="3"
.unit="стакан"
"Мука"
ingredient
.amount="0.25"
.unit="грамм"
"Дрожжи
ingredient
.amount="1.5"
.unit="стакан"
"Тёплая вода"
ingredient
.amount="1"
.unit="чайная ложка"
"Соль"
instructions
step
"Смешать все ингредиенты и тщательно замесить."
step
"Закрыть тканью и оставить на один час в тёплом помещении."
/*step
"Почитать вчерашнюю газету."
- это сомнительный шаг...*/
step
"Замесить ещё раз, положить на противень и поставить в духовку."Важно
Формат придуман как компактная альтернатива имеющимся. Потому указание типов данных имеют явный, но компактный вид:
Information Data .value1=0x01 Два hex-разряда - 8 бит (незначащие нули вместо слова byte) .value2=0x0001 Четыре hex-разряда - 16 бит (незначащие нули вместо слова word) .value3=0x00000001 Восемь hex-разрядов - 32 бита (незначащие нули вместо слова dword) .value4=0001 Восьмиричная величина - 8 бит .value5=0000001 Восьмиричная величина - 16 бит .value6=000000000001 Восьмиричная величина - 32 бита .value7=+001 Десятичная величина - 8 бит (не восьмиричное) .value8=-00001 Десятичная величина - 16 бит (не восьмиричное) .value9=+0000000001 Десятичная величина - 32 бита (не восьмиричное) .param1=-1.0 Вещественный тип обычной точности (float) .param2=+1.00 Вещественный тип двойной точности (незначащие нули указывают на double) .param3='Text\0' Текстовая строка ascii (1 байт на символ) .param4="Text\0" Текстовая строка unicode (2 байта на символ) .param5=!!FALSE Либо !!TRUE - 1 бит информации (тип boolean) .doubt1=8:reference Ссылка на что-нибудь (8 байт) .doubt2=4:refer.url Ссылка на что-нибудь вложенное (4 байта) .doubt3=2#refer.url Размер чего-нибудь в байтах (2 байта величины объёма) .doubt4=+2:refer.url Ссылка на что-нибудь вложенное относительно родителя (2 байта смещения) .doubt5=-1#refer.url Индекс чего-нибудь вложенного внутри родителя от конца (1 байт порядкового)
Файл p32x32.bmp:
Bitmap
BITMAPFILEHEADER
bfType='BM' Тип файла
bfSize=4#$ Размер файла
bfReserved1=0x0000
bfReserved2=0x0000
bfOffBits=+4:$.Data Смещение до данных изображения
BITMAPINFOHEADER
biSize=4#$$ Размер текущей структуры
biWidth=+0000000032 Десятичное 32 (LONG)
biHeight=+0000000032
biPlanes=+00001 Десятичная 1 (WORD)
biBitCount=+00024 Десятичное 24 (WORD)
biCompression=0x00000000 BI_RGB (DWORD)
biSizeImage=4#$.Data Размер данных изображения
biXPelsPerMeter=+0000000000
biYPelsPerMeter=+0000000000
biClrUsed=0x00000000
biClrImportant=0x00000000
Data
.@"p32x32.bit" Включить данные из файла с дискаВариант с жёстким синтаксисом.
Символы табуляции указывают своим количеством на пренадлежность к той или иной
группе структур.
Пример:
Structure_1 Открытие новой структуры в корневом уровне иерархии
.property_ascii Внедрение нового свойства в структуру
:'ascii text' Заполнение свойства 10-ю однобайтовыми символами ascii
.property_unicode
:"unicode текст" Заполнение свойства 13-ю двухбайтовыми символами unicode
.property_utf-8
:`utf-8 текст` Заполнение свойства 16-ю байтами смеси ascii и utf-8
.property_char
:0x01 Заполнение свойства 1-м байтом
.property_short
:0x0001 Заполнение свойства 2-мя байтами
.property_long
:0x00000001 Заполнение свойства 4-мя байтами
.property_hyper
:0x0000000000000001
.property_float
:1.0
.property_double
:1.00hr:Candidate
.xmlns:hr
='http://www.hr-xml.org/3'
.xmlns:ccts
='urn:un:unece:uncefact:documentation:1.1'
.xmlns:xsi
='http://www.w3.org/2001/XMLSchema-instance'
.xmlns:oa
='http://www.openapplications.org/oagis/9'
hr:DocumentID
'000000001'
hr:CandidatePerson
hr:PersonName
hr:FormattedName
'Blimpo Togwer'
oa:GivenName
'Blimpo'
hr:FamilyName
'Togwer'
hr:Communication
hr:ChannelCode
'Mail'
hr:Address
oa:AddressLine
.sequence
='1'
'5555 Yellow Brick Road'
oa:AddressLine
.sequence
='2'
'RR #1'
oa:CityName
'Lesser Village'
oa:CountrySubDivisionCode
'KKK'
hr:CountryCode
'XX'
oa:PostalCode
'AAA BBB'Кстати. Мне очень смутно, но кажется, что в ИТ есть где-то небольшое упущение...
Вот опыты с vlc-трансляцией, что ставили мою машину на колени, заставили задуматься...
Вот возьмём обычное ТВ. Там к одному кабелю можно сотни телеков подключить и будет норма (относительная)...
А вот в сети радио и телевиденье требует по сетевым стандартам, чтобы каждый клиент отрабатывался отдельным потоком процессора (с этими грёбанными функциями accept, send/recv)...
Почему нет протокола, где не требуется регистрация клиента и выделения ему отдельного потока?
Я знаю, что технологически это не возможно или очень сложно.
Но, если взять Zyxel и dialup-связь, есть такие приёмы, где можно было врубиться к телефону соседа и модемом "удить" его интернет-поток...
Почему в глобалке нельзя придумать так, чтобы когда маршрут доходит до определённого пункта, на аппаратном уровне все сто и тысяча абонентов могли бы качать живой поток видео без нагрузки на сервер?
Тупо, настраивается тот пункт (свитч/хаб или фиг знает что) так, чтобы он сам качал видео с такого-то сервера, а все клиенты тянули бы с него...
int8, int16, int32, int64 и т. д., и uint8, uint16, uint32, uint64.
Если говорить о венгерской, эти int'ы и uint'ы - безобразие.
А так, подчёркиваю, во внутренних проектах не зря всё назвал несколько экзотически:
Char, Slab, Word, Note, Page, Book.
Так, в Verilog-листинге при манипуляциях с регистрами удобно писать R1S3 - Register #1 Slab #3...
Слово - не из двух букв.
Как можно заметить, все обозначения имеют четыре буквы.
Две буквы - слог. Два слога - слово. Два слова - запись.
Две записи - страница. Две страницы - книга. Две книги - связка (Link).
Две связки - посылка (Mail). Две посылки - помост (Dais).
Два помоста - комната (Room). Две комнаты - холл (Hall).
Два холла - ферма (Farm). Две фермы - площадь (Area) - 32768 бит.
И всё в таком духе... ;)
То же самое можно сказать про элементарные частицы: Назовём Нейтрон - двойным электроном, а Протон - учетверённым.
К чему я клоню. Все эти byte/tbyte, word/qword - слишком прагматично. Иначе бы в Си не ввели бы char/short/int/long/hyper...
Сами попробуйте весь проект переписать с int8/int16/int32/int64... Мозги вскипят!
Просто я решил дать волю фантазии, ограничив её четырьмя буквами...
Выдыхай.... :)
Aslan
> всесоюзная библиотека
Ностальгируешь?
> четверная полка, двойной шкаф
Шкаф с антресолями.
> абзац
Полный абзац :)
Если Вы заметили,
Char, Slab, Word, Note, Page, Book...
- всё ограничено четырьмя буквами и начальные буквы - уникальны и не повторяются. Сомневаюсь, что Ваш сарказм "страниц, разворотов, глав, томов" и т.п. можно оформить в 4 буквы целых слов (Para - не Параграф. И уже есть Page).
Тема в архиве.