Компилятор GCC

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

В Borland C это выглядит так: https://i.imgur.com/lCM8Lao.png

Это всё нерелевантно на x86-64.

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

Но зачем ? Что тебе это даст ?

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

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

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.

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

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

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

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

Хотя это скорее не совсем то, что мне надо. Нужно показать разницу между тем, сколько занимает ячейка памяти байт в модели 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));
}

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

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

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

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>

32битную libc поставь?

Ой, это надо libc6-dev-i386.

libc6-dev:i386?

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

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

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

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

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

Но я хочу увидеть сам реальный результат.

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

Нет, нужно конкретно модель памяти small и large

В том же Borland C это работает так: small - https://i.imgur.com/GvtQvHi.jpg large - https://i.imgur.com/e3dB4Ol.jpg

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

Как бы да

/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

DosBox + Borland C

/thread

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

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

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

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

Тогда старая винда в виртуалке + сабж

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

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

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

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

Или нужен конкретно Windows XP?

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

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

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

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

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

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

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

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

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

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

зачем?

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

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

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

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

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

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

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

Так и сделал.

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

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

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

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

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

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

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

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

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

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