LINUX.ORG.RU

Подход к портированию, если sizeof(char)=2

 , ,


0

3

Ищу подход, как с наименьшими усилиями портировать код под архитектуру, где sizeof(char)=sizeof(int_8t)=2. Проблема: обмен данными с хостом, у которого привычный размер char, равный 1.

Обычные объявления

typedef struct foo {
  char f1;
  char f2;
};
можно, на первый взгляд, обойти битовыми полями:
typedef struct foo {
  char f1 : 8;
  char f2 : 8;
};
А как элегантно справиться с
typedef struct foo {
  char f[6];
};
?

★★★★★
Ответ на: комментарий от dvl36

ну дык и с чем ты споришь? Что

формально — да. Реально он всегда делится на 16 как минимум. Кстати, последние биты указателей можно в своих целях использовать, ибо для адресации они давно не нужны.

Что-то эти «сентенции» вызывают сомнения.

Теперь у тебя сомнений нет? Или ещё есть?

Ясно, что элементарной единицей адресации в памяти является байт-октет

Ты с этим неистово споришь.

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

Не не угадал. Из всего вышеперечисленного я очень поверхностно знаком только с явой. Си, иногда пару строк asm-а, и не x86.

ну извини. Я не виноват, что ты там чего-то не знаешь…

drBatty ★★
()
Ответ на: комментарий от drBatty

Теперь у тебя сомнений нет? Или ещё есть?

Устал я уже, конечно... Для тех, кто «в теме», уже понятно что ты слит, и очень конкретно слит, и не мной одним слит.

ну извини. Я не виноват, что ты там чего-то не знаешь…

Этот трюк, он подходит только для ООП языков, где простые типы могут быть переопределены и поэтому используеться схема с указателями и динамическим выделением памяти даже для простых типов. Приведеная тобой статья собственно об этом и говорит. Для человека, использующего Си, делать так не имеет смысла и знать мне это просто совершенно не нужно.

dvl36
()

Ты гонишь. sizeof(char) == 1 по стандартам С и С++. Есть еще CHAR_BITS для определения количества битов в char'е.

anonymous
()
Ответ на: комментарий от dvl36

Устал я уже, конечно... Для тех, кто «в теме», уже понятно что ты слит, и очень конкретно слит, и не мной одним слит.

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

Единственное, что очевидно, что ты даже материал по теме нагуглить не в состоянии.

Этот трюк, он подходит только для ООП языков, где простые типы могут быть переопределены и поэтому используеться схема с указателями и динамическим выделением памяти даже для простых типов. Приведеная тобой статья собственно об этом и говорит. Для человека, использующего Си, делать так не имеет смысла и знать мне это просто совершенно не нужно.

т.е. ты мне предлагаешь сейчас нагуглить пруф того, что это в pure C применяется? Нет уж. Учись сам искать.

И да, слив засчитан. Раз всё-таки ты уже не сомневаешься, что «подходит». А уж доказывать область годности — мне действительно лень.

drBatty ★★
()
Ответ на: комментарий от drBatty

Что за бред? Если я выделю массив char'ов, то я смогу адресовать каждый из элементов. Ты мешаешь кучу вещей в одну...

anonymous
()
Ответ на: комментарий от superhackkiller1997

Да, тяжелый случай. Архитектуру с аллокатором путает. Уже 3 или 4 человека пытаются втолковать - не доходит.

Безнадежно, все опустили руки.

dvl36
()
Ответ на: комментарий от Anon

sizeof(char) не может быть 2. Он гарантировано == 1. Другое дело, что он не обязан быть 8бит.

anonymous
()
Ответ на: комментарий от anonymous

Что за бред? Если я выделю массив char'ов, то я смогу адресовать каждый из элементов

см. выше мои посты. Можешь, и с этим я не спорил.

drBatty ★★
()
Ответ на: комментарий от drBatty

я аж обосрался.

бла-бла.

а что у тебя выдал этот код:

Добавь к нему еденичку - будет у тебя указатель не кратный 16 и будет работать, реально? Такое возможно? Как так, да?

мало кого волнуют догадки школьника, факт остаётся фактом, указатель кратен 16.

Твоё неосиляторство матчасти просто поражает моё воображение, ты что несёшь?

Осиль m32 и m64, осилить устройства маллока, осиль поглядеть каким образом он даже у маллока кратен 16.

удивлюсь. Если ты код покажешь. А пока ты просто слился.

Ты реально что-то путал, ты абсалютно анскильное сущство, которое недостойно даже говорить и смной и я терплю тебя, ради того, чтобы сделать тебя хоть каплю скилловей, а ты мне грубишь?

Я просто поржаюсь, как такие могут даже в мечтах пытаться быть на ровне со мной, а уж умничать и питросянить мне тут.

[463358.801129] ffff880116c75e70, ffff880116c75e68, ffff880116c75e60, ffff880116c75e58

cat /sys/kernel/slab/123/align 
8

ну спасибо, деточка, что ты мне разрешил. Я тебя не забуду.

Ах да, какая детская отмазочка. Ткнул, а там пустота, а пустоту зассал показать, а вот балаболить он горазд.

хм… «Анскильная балоболка» типа меня, таки обладает «скиллбейзед»? Продолжаем делить на ноль? Я же ламо, и этого не мог знать по определению, ведь ты, светочь, мне об этом не сказал.

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

Тебе вроде гвоорили в вузике, что есть какие-то сегфолты, странички и т.п., но дальше этого не ушло, такая история и с хабром.

superhackkiller1997
()
Ответ на: комментарий от drBatty

я конечно очень рад за вас. Особенно учитывая, что вы все, в своей теме, храните гробовое молчание.

Ну, не все же круглосуточно сидят на ЛОР-е. Люди еще и делом занимаются.

Я даже и не понял, в чём ты там вообще сомневался.

Подход к портированию, если sizeof(char)=2 (комментарий)

Единственное, что очевидно, что ты даже материал по теме нагуглить не в состоянии.

Конечно, ведь ты даже и не сообщил о какой теме ты говоришь. Теперь понято - об аллокаторах.

И да, слив засчитан. Раз всё-таки ты уже не сомневаешься, что «подходит». А уж доказывать область годности — мне действительно лень.

Ну сомневаться, а не быть бронелобым, как некоторые - это нормально. И конечно, если уж обгуглиться, то, вероятно, можно найти какое-то крайне редкое применение. У меня нет на это времени. Я и так что-то много стал уделять внимания этой дискуссии.

dvl36
()
Ответ на: комментарий от superhackkiller1997

Ололо, шваль, попробуй невыровненный доступ на Alpha, например.

anonymous
()
Ответ на: комментарий от anonymous

Я прокомментировал то, что ты написал. А написал ты чушь. Если ты ошибся, то так и скажи.

я зарегистрирован, пишу с одного ника. И писать по 20 раз одно и тоже в одном топике мне лениво. Если ты не в состоянии осилить топик целиком, не удивляйся, что мои посты тебе непонятны и кажутся чушью.

drBatty ★★
()
Ответ на: комментарий от dvl36

Ну, не все же круглосуточно сидят на ЛОР-е. Люди еще и делом занимаются.

писать о том, какой ты крутой и какой ты умный, по сравнению со мной, у тебя времени почему-то хватает.

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

Подход к портированию, если sizeof(char)=2 (комментарий)

я не ленивый, ещё раз процитирую.

И даже поясню, что я имел ввиду: слово «реально» тут значит «в реальных CPU». Например x86 давно уже просто не умеет читать по одному байту. Уже с первопня читалось не меньше 8и байт, что требовало 4х байтные модули ставить по две штуки. Потому, если ты решишь прочитать один байт, у тебя всё равно прочитается как минимум 8 штук, и уже внутри CPU ты будешь фильтровать нужный. По этой причине, выделять и использовать память с гранулярностью <8 нет никакого смысла, ибо быстрее не будет. Если тебе жалко места, можешь в одном куске памяти хранить несколько чисел.

Конечно, ведь ты даже и не сообщил о какой теме ты говоришь. Теперь понято - об аллокаторах.

Ну если-бы ты немного подумал, то понял-бы, что для стека этот вариант неприменим. Как и для статических данных. Если не можешь/не хочешь думать, спроси. А вот додумывать за меня не нужно.

И конечно, если уж обгуглиться, то, вероятно, можно найти какое-то крайне редкое применение. У меня нет на это времени. Я и так что-то много стал уделять внимания этой дискуссии.

ну и закроем дискусс. Эти мои биты действительно применяются на настолько низком уровне, что для прикладного программиста практически бесполезны(если они полезны, то в твоём PHP они уже работают).

drBatty ★★
()
Ответ на: комментарий от drBatty

писать о том, какой ты крутой и какой ты умный, по сравнению со мной, у тебя времени почему-то хватает.

Ну что ты. Я на личности не начинал переходить, это твоя заслуга.

И даже поясню, что я имел ввиду: слово «реально» тут значит «в реальных CPU». Например x86 давно уже просто не умеет читать по одному байту.

Да, Кэп, зависит от ширины шины данных. В 8086 тоже по 2 байта передавалось, а в 8088, например, один. Но ты ведь совсем не об этом говорил. А сейчас, пару дней погуглил, и опять начитался всякого, по диагонали. Почитай еще про ras и cas. Затем про align. Может поймешь зачем он нужен.

Если тебе жалко места, можешь в одном куске памяти хранить несколько чисел.

Есть одна проблема. По одному байту, целому числу, long-у или указателю, выделять память malloc-ом, с помощью аллокатора, не принято. Если это и делает кто-то, то это какой-то весьма специфический код. Говнокодеры это конечно могут делать везде, но это _очень_ неэффективно, как с точки зрения расхода памяти, так и cpu.

ну и закроем дискусс. Эти мои биты действительно применяются на настолько низком уровне, что для прикладного программиста практически бесполезны(если они полезны, то в твоём PHP они уже работают).

Да, вот на ПХП недавно писал:

   parm[0] = bits[0];
   parm[1] = (bits[1] << 2) | (bits[2] >> 6);
   parm[2] = ((bits[2] & 0x3f) << 2) | (bits[3] >> 6);
   parm[3] = (bits[3] & 0x20) >> 5;
   parm[4] = ((bits[3] & 0x1f) << 8) | bits[4];
   parm[5] = (bits[5] >> 4) & 0xf;
   parm[6] = ((bits[5] & 0x0f) << 3) | ((bits[6] >> 5) & 0x7);
   parm[7] = bits[6] & 0x1f;
   parm[8] = (bits[7] << 5) | (bits[8] >> 3);
   parm[9] = ((bits[8] & 0x7) << 1) | (bits[9] >> 7);
   parm[10]= (bits[9] & 0x7f);
Отлично работают :-D

P.S. Угомонился бы ты уже, а.

dvl36
()
Ответ на: комментарий от dvl36

Да, Кэп, зависит от ширины шины данных. В 8086 тоже по 2 байта передавалось, а в 8088, например, один. Но ты ведь совсем не об этом говорил. А сейчас, пару дней погуглил, и опять начитался всякого, по диагонали. Почитай еще про ras и cas. Затем про align. Может поймешь зачем он нужен.

я читал.

Если тебе жалко места, можешь в одном куске памяти хранить несколько чисел.

Есть одна проблема. По одному байту, целому числу, long-у или указателю, выделять память malloc-ом, с помощью аллокатора, не принято. Если это и делает кто-то, то это какой-то весьма специфический код. Говнокодеры это конечно могут делать везде, но это _очень_ неэффективно, как с точки зрения расхода памяти, так и cpu.

ты разве не понимаешь, или делаешь вид? НЕВЫГОДНО. А принято/непринято — никого не волнует. Дорого выходит побайтно выделять, как раз именно потому, что побайтно CPU НЕ читают. О чём я и говорю.

Да, вот на ПХП недавно писал:

Угомонился бы ты уже, а.

drBatty ★★
()
Ответ на: комментарий от drBatty

ты разве не понимаешь, или делаешь вид? НЕВЫГОДНО. А принято/непринято — никого не волнует.

Что за перекруты! Непринято потому что неэффективно! Или, как ты говоришь, невыгодно.

Дорого выходит побайтно выделять, как раз именно потому, что побайтно CPU НЕ читают. О чём я и говорю.

Опять бред начался! Тебе тут уже объясняли про оверхед аллокатора. Нихрена ты не понял!

Будем повторять.

Так вот,если ты выделяешь один байт, ты теряешь много памяти, в зависимости от реализации конкретного аллокатора и его настроек, и еще, ОГРОМНУЮ кучу cpu тактов, на работу этого аллокатора. Поэтому используют стек и статику. Если нужно много, выделяют сразу массив/буфер, что позволяет свести к минимуму оверхед аллокатора на один элемент.

Угомонился бы ты уже, а.

Я уже и угомонился было, подумав что ты пошел на поправку. А тут опять рецидив произошел.

Давай показывай свой «низкоуровневый» код, «гений» программирования. Даже и не думай показывать чужой!

dvl36
()
1 июля 2013 г.
Ответ на: комментарий от tailgunner

Вобщем, в линуксе с самодельным 16-битным char'ом код уже давненько как заработал, а вот с этим DSP выяснилось, что при использовании gcc'измов необходимо обновить code generation tools. Это потребовало обновления CCS 3.3 до SR 12.1, а из-за этого и драйвера JTAG'а. В итоге дебаггер в произвольных местах просто останавливается или не может выполнить step over. Поддержка быстренько ответила, но, когда выяснилось, что стандартный совет не помогает, замолчала.

Теперь думаю, как бы тестировать уже почти на ДСП, но обойтись в большинстве случаев без реального дебаггера. Чтобы тестировать код по передаче данных, надо бы как-то получить что-нибудь снаружи CCS (какой-нибудь виртуальный последовательный порт или pipe) и внутри тоже. Но как?

Уже установил CCS 5.4 под линукс в free-режиме.

gag ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Сколько уже лет у них эта линукс-совместимая эклипс-версия, а симуляторы C55x по-прежнему отсутствуют, как и некоторые эмуляторы. Снова без венды никуда.

gag ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Не-а. Ему с чего-то нужно обязательно установить vc-redist-2012, который приводит к давно известной ошибке, которую вайновцы упорно игнорируют.

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

gag ★★★★★
() автор топика
7 октября 2013 г.
Ответ на: комментарий от true_admin

Байт - 8 бит (правильнее было бы сказать «октет»); наименьшая адресуемая единица - 2 октета; и получается, что ты просто не можешь сделать char меньше 16 бит.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

наименьшая адресуемая единица - 2 октета

Я не понимаю о чём ты. Если я сделаю массив char array[10] то разве элементы не будут идти подряд без интервалов и sizeof(array) == 10?

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

наименьшая адресуемая единица - 2 октета

Я не понимаю о чём ты

Помедитируй над этим. Возможно, тебе будет понятнее выражение «16-битовый байт».

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

Фу таким быть :(

Ну не знаю я, как выразиться яснее.

Оно что ли двухбайтное внутри проца?

Ыыы... считай, что перед выдачей значения регистра на шину адреса процессор сдвигает это значение на 1 бит влево, а потом читает с шины данных 16 бит.

http://en.wikipedia.org/wiki/Memory_address

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

а потом читает с шины данных 16 бит.

Так разве это что-то меняет с точки зрения программы? А на «физическом» уровне он, скорее всего, считывает не меньше чем длина линии кэша L1 (=64байта для современных интелей если верить стэковерфлоу).

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

а потом читает с шины данных 16 бит.

Так разве это что-то меняет с точки зрения программы?

По сравнению с чем? Если бы он читал 8 бит, байты по нечетным адресам были бы недоступны.

А на «физическом» уровне он, скорее всего, считывает не меньше чем длина линии кэша L1

Рассматривался учебный пример, абстрактный сферический процессор в вакууме.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

По сравнению с чем?

Если я тебя правильно понял то ты говоришь что char на самом деле два байта. А по мне так факт того что контроллер памяти оперирует только более крупными блоками не превращает char в два байта. Т.е. char таки имеет длину 1 байт и отсюда вытекают его свойства: он переполняется после 255 (127), занимает 1 байт в памяти итд итп. Поэтому я не понимаю как надо интерпретировать фразу «16-битный байт».

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

контроллер памяти оперирует только более крупными блоками

tailgunner> перед выдачей значения регистра на шину адреса процессор сдвигает это значение на 1 бит влево

А вообще, забей. Вряд ли ты встретишься с такой экзотикой.

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

обоже. только не это снова.

байт, по определению — наименьшая адресуемая единица памяти. char, в соответствии со стандартом языка — тоже наименьшая адресуемая единица памяти. у процессоров данной архитектуры эта единица длиной в 16 бит. вот буквально: адрес 0x0000: 16 бит, адрес 0x0001: ещё 16 бит и т.д.

НЕТ способа адресовать отдельный октет, НЕТ! доступиться к отдельным октетам (полубайтам, в данном случае) возможность есть, но с помощью отдельного шаманства.

и char на этом процессоре таки НЕ переполняется после 255, и, таки да, занимает 16 бит. при вводе/выводе символьной ASCII-строки (например, в последовательный порт) старшие октеты просто обрезаются. но в памяти они продолжают храниться.

anonymous
()
Ответ на: комментарий от anonymous

И что? Будто бы 16-битные системы не умеют работать с 32-битными числами. Тут тоже можно выкрутиться и забульбенить свой char, которых в одно слово будет 2 штуки влезать. Тормознуто, зато 8 бит и экономия памяти ☺

Anon
()
Ответ на: комментарий от Anon

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

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

И? В чем проблема? Скажем, твой char *a = &#34;жопа&#34; в 16-битной имеет вид 0x00d6 0x00cf 0x00d0 0x00c1 0x0000, а ты хочешь сделать нормальные 8-битные char'ы: 0xd6 0xcf 0xd0 0xc1 0x00. Тупо пакуешь по 2 соседних буквы, получая 0xd6cf 0xd0c1 0x0000.

Для чтения считываешь очередную пару a[0]==0xd6cf, первая буква есть (a[0] >> 8) & 0x00ff, вторая — a[0] & 0x00ff. И что?

Anon
()
Ответ на: комментарий от Anon

В чем проблема?

В том что ты не прочитал дискуссию ниже поста на который ты отвечал. И даже мой пост не прочитал.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Ты фигню сказал насчет переполнения unsigned char после 255. Если он 16-битный, то переполняться будет после 65535.

Anon
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.