LINUX.ORG.RU

Лолчто? -m32 тебе надо?

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

Но тем не менее мне надо сделать тоже самое в GCC, что и в Borland C: скомпилировать код с нужной моделью памяти.

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

поройся в архивах. Может в первых gcc это есть

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

RTFM.

       -mcmodel=tiny
           Generate code for the tiny code model.  The program and its statically defined symbols must be within 1MB
           of each other.  Programs can be statically or dynamically linked.

       -mcmodel=small
           Generate code for the small code model.  The program and its statically defined symbols must be within 4GB
           of each other.  Programs can be statically or dynamically linked.  This is the default code model.

       -mcmodel=large
           Generate code for the large code model.  This makes no assumptions about addresses and sizes of sections.
           Programs can be statically linked only.
Это цитата из «man gcc».

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

Благодарствую. Но gcc --target-help был слишком большим, мог и пропустить.

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

Видимо, от версии к версии что-то менялось:


gcc: note: valid arguments to ‘-mcmodel=’ are: 32 kernel large medium small

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

tiny на x86_64 сегодня не сработала, да. А вот small и large вполне работают.

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

Хотя это скорее не совсем то, что мне надо. Нужно показать разницу между тем, сколько занимает ячейка памяти байт в модели small и large. Я компилирую, и у меня одинаково почему-то.

#include <stdio.h>
#include <stdlib.h>

int main(){
int number, *p_number;
p_number = (int*)malloc(sizeof(int));
*p_number = 10;
printf("Pointer adress: %p \n", p_number);
printf("Size of the pointer: %d \n", sizeof(p_number));
printf("Link adress: %d \n", *p_number);
printf("Size of the link: %d \n", sizeof(*p_number));
}

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

Тебе уже сказали, что это уже не релевантно. Собирай с -m32, может на 32битах ещё сработает.

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

Pointer adress: 0x55679b7ad260 Size of the pointer: 8 Link adress: 10 Size of the link: 4

Pointer adress: 0x5559c9a1b260 Size of the pointer: 8 Link adress: 10 Size of the link: 4

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

Не особо собирается

In file included from main_17.c:1:0:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: Нет такого файла или каталога
 #include <bits/libc-header-start.h>

HonkyDot ()
Ответ на: комментарий от anonymous
Чтение списков пакетов… Готово
Построение дерева зависимостей       
Чтение информации о состоянии… Готово
Уже установлен пакет libc6:i386 самой новой версии (2.27-3).
Обновлено 0 пакетов, установлено 0 новых пакетов, для удаления отмечено 0 пакетов, и 0 пакетов не обновлено.
HonkyDot ()
Ответ на: комментарий от anonymous

Выше написал. Ну вот, предположим, что компилируется с моделью памяти small, как мне изменить на large?

Pointer adress: 0x57ae7160 
Size of the pointer: 4 
Link value: 7 
Size of the link: 4 

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

Оно не поддерживает никакой -mcmodel увы

cc1: error: code model ‘large’ not supported in the 32 bit mode

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

Может тогда сманеврировать и просто разницу между 32бит и 64бит режимами показать?

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

Размер указателя как раз будет отличаться.

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

А если передать -m16? Вроде пишут что gcc такое тухлое легаси не поддерживает.

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

Как бы да

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /lib/x86_64-linux-gnu/libgcc_s.so.1 when searching for libgcc_s.so.1
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/7/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc
collect2: error: ld returned 1 exit status

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

Я такой нуб, что у меня даже через эмулятор не получается сделать это :(

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

Зачёт по лабораторной работе.

институт времени ? специалист по работе в прошлом ??

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

Но у меня же и так есть Borland C и DosBox, почему оно не работает?

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

Нет, всего лишь компьютерный инженер.

«компьютерный инженер» жезть :-)

беги оттуда..

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

На x86-32 нерелевантно, а вот на 64 как раз релевантно.

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

Если ты так думаешь, то постарайся помочь с моделью памяти.

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

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

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

Давным давно процессоры Intel были 16 битными. Соответственно, максимально могли адресовать 64 кб ОЗУ. Времена шли и это оказалось мало, но терять обратную совместимость не хотелось. И поэтому Intel придумали костыль - появились так называемые сегментные регистры (тоже 16 бит). Реальный адрес получался сдвигом значения сегментного регистра на 4 бита (фактически умножение на 16) и прибавлением смещения (старого адреса). Таким образом стало возможно использовать 1 мб ОЗУ вместо 64 кб. При этом старые программы про сегментные регистры не знали, ос загружала некоторое дефолтное значение и программа работала с одним сегментом как будто это была вся доступная память.

Компиляторы того времени умели компилировать программу в двух режимах - старом и новом. В первом случае программа делала вид, что не знает ничего о сегментах (работала в рамках того, что дала ей ОС) и поэтому можно было в качестве указателя использовать только 16битное смещение. В новом же режиме программа знала про сегменты и указатели становились 32 бита, потому что хранили две части адреса - сегмент и смещение. Таким образом, если программе было нужно мало памяти, можно было сэкономить на размере указателей, да ещё и получить совместимость с совсем древними процессорами.

Время шло и пришли 32 бита. Смещения в сегментах стали 32 битными, а сами значения сегментных регистров изменили смысл (теперь это не просто старшая часть адреса, а индекс в таблице ОС, которая хранить больше инфы про сегмент). Смысла использовать сегменты для увеличения объёма адресуемой памяти не стало (смещения и так 32 бита, а больше 4 ГБ те процессоры все равно не умели). Так что ни один 32битный компилятор с сегментацией работает не умеет и делает вид, что её нет (не трогает содержимое сегментных регистров и поэтому использует то, что дала ОС). Да и нельзя иначе - теперь значения сегментов это не кусок адреса, а индекс в таблице и только ОС знает зачем какие сегменты нужны. Соответственно, при компиляции в 32 бита нету двух разных режимов.

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

Так что понятие модели памяти в прежнем значении к 32 и 64 битными компиляторам (не только GCC, но и MSVC и любой другой), не применимо вообще. Опция с таким именем влияет совсем на другие вещи и имеет иной смысл.

Твоя лабораторная имеет смысл исключительно в DOS. Среда разработки и компилятор нужны соответствующие.

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

ты забыл сказать зачем это все нужно в реальной жизни в 2018?

зачем?

стать великим историком компьютерного программирования или шо я нипойму

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

Лучший ответ из всех предоставленных, и скорее истинный, большое спасибо.

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

Потому что у препода методичка была написана во времена DOS, а переписать её некому.

Для других предметов вроде физики или математики это не особо страшно (теорема Пифагора или законы Ньютона никогда не потеряют актуальности), а вот в it задержка в десятилетия делает многие знания абсолютно неприменимыми на практике (не все кончено).

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 3)
Ответ на: комментарий от HonkyDot

Судя по ошибкам таки поддерживает. Беда в том, что у него нет libc под 16 бит, в итоге получаем ошибки линковки (не компиляции). Тебе надо откуда-то достать 16 битные версии всех библиотек. Только вот вторая засада в том, что Linux не умеет исполнять 16 битные бинарники (последние версии винды тоже разучились, 64 битные редакции никогда не умели сразу), так что ты всё равно не запустил бы результат.

Тебе надо ещё заставить GCC генерировать вместо elf досовские бинарники, что может быть нетривиальной задачей.

В общем, проще забить и сделать с помощью инструментов того времени.

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

Но тем не менее мне надо сделать тоже самое в GCC, что и в Borland C: скомпилировать код с нужной моделью памяти.

ЕМНИП, порт gcc под DOS(djgpp) никогда не умел 16-бит.

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

Кстати, чисто технически что-то вроде сегментации применяется на многих микроконтроллерах (pic, например), поскольку разрядность у них 16 бит в лучшем случае, а больше 64 кб ОЗУ таки хочется. Но там вообще своя атмосфера.

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

«технически» это типо теоретически?

а практически знаешь как?

практически так что каждый контроллер/спец-процессор имеет свой компилятор в котором твоя Си программа собирается одной кнопкой из гуя(или имеет порт gcc компилятора), и тебе глубоко пофик как там внутри оно работает

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

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

KivApple ★★★★★ ()
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

блять ну что за бредовый теоретизм

на асемдлере используют пару готовых шаблонов 20 лет назад написанных, правя там пару строк за минуту, это для контроллеров с 1мб памяти

99% остального имеет по 64мб+ памяти и 500мгц проц(арм/ппц или аналог), туда хоть джава машину можно пихать без ущерба производительности

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