dlcorp.nedopc.com (ZX-Форум) (21+, запрещено для детей)

DimkaM wrote:to lvd, за пруф сойдёт?!

Мне пруф нужен был, что в чаре нельзя хранить числа, причём пруф от фк0. В том, что ты показал, ничего удивительного не вижу, так и должен работать любой конь пилятор.

вернул стартап в на место.
Вопрос снят.
Продолжаем срач.

Как хранить однобайтовую дату в условиях z80&IAR ?
Я так думаю в начале проги выделить static int dataspaces[100500]
И оное юзать по своему усмотрению, чтоп компилятор самодеятельностью незанимался.

DimkaM wrote:И оное юзать по своему усмотрению, чтоп компилятор самодеятельностью незанимался.

и еще написать свой маллок и фрее, да?

DimkaM wrote:текстовый 80х25. На АТМе с 90х годов существует. На Еве тоже, тока добавлен ещё один режим однопаговый.

Дазнаю,но "банкомат" мне тогда был не по зубам, т.е. не по карману, а сейчас вроде бы и надобностей нетуть.

lvd wrote:Это пруф, что в чаре нельзя хранить числа?

Что такое "пруф"? Выражайся на нормальном языке. char предназначен для хранения символов. Хранить-то можно, но ещё раз -- char предназначен для символов. А то у некоторых и bit есть...

Как правильно дезсофт заметил, тип с неизвестной знаковостью и разрядностью ОХУЕННА подходит для вычислений... и таки да, до int расширять будет ХУЙ ЗНАЕТ КАК.

В ISO9899 предусмотрены uint8_t для того, например.

"Я тут накомпилировал и у меня всё заебись" -- тоже охуенна глупый аргумент. Ты накомпилируй на более другой платформе для начала и посмотри.

fk0 wrote:"Я тут накомпилировал и у меня всё заебись" -- тоже охуенна глупый аргумент. Ты накомпилируй на более другой платформе для начала и посмотри.

Если я накомпилирую uint8_t на десофт-платформе, где чар 16 бит и это минимальный размер, то что будет?

lvd wrote:Если я накомпилирую uint8_t на десофт-платформе, где чар 16 бит и это минимальный размер, то что будет?

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

deathsoft wrote:Там просто нет uint8_t. Компилятор ошиьку выдаст что тип не поддерживается.

Ждём комментария fk0: что лучше, если программа не скомпилируется с uint8_t, или будет (возможно бажно) работать с char.

Лучше, если она будет безбажно работать с uint_fast8_t.

Дезсофт забыл сказать, на 16/32-битных бывает char и 8-битный чаще. Это только у DSP извращения. Но вот цена обращения к 8-битной переменной, да ещё без выравнивания, зашкаливает на фоне 16/32-битных обычных переменных. В лучшем случае лишние команды CPU. В худшем исключение на невыравненном обращении и программная коррекция результата -- over дохерадцать тактов.

fk0 wrote:Лучше, если она будет безбажно работать с uint_fast8_t.

что ничем не отличается от char, который должен быть минимум 1 байт.

fk0 wrote: Но вот цена обращения к 8-битной переменной, да ещё без выравнивания, зашкаливает на фоне 16/32-битных обычных переменных. В лучшем случае лишние команды CPU. В худшем исключение на невыравненном обращении и программная коррекция результата -- over дохерадцать тактов.

помоему ты гонишь -- любой отдельный байт находится внутри выровненного слова, будь оно 16битное, 32битное или ещё какое.