Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Инструменты программирования  (Прочитано 1680 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« : 27-01-2017 14:22 » 

Доброго дня.

В виду регулярного затрагивания темы по х64 заинтересовался: кто и чем пользуется?

Стал изучать проблему более пристально, сперва обследовал NASM, как оказалось, современная версия позволяет собирать в объектный файл формата elf64. Но непонятно чем его линковать?

По компиляторам из-за нежелания использовать MSVC в доступном обозримом видится: MinGW-w64. Кто-нибудь им пользовался? Или есть ли лучшие аналоги, особенно, в плане легковесности?

Напомню, что комплект для Windows на настоящий момент у меня представляет из себя: NASM, ALINK и TCC.

Добавлено через 1 час, 10 минут и 8 секунд:
Установил для пробы: gcc (i686-posix-dwarf-rev1, Built by MinGW-W64 project) 6.3.0

Проект с ключом -m32 собирается,
с ключом -m64 нет: sorry, unimplemented: 64-bit mode not compiled in #include <stdio.h>

Странно, библиотеки похоже тоже должны быть другими, хоть и комплект один?
« Последнее редактирование: 27-01-2017 15:32 от Aether » Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 27-01-2017 15:36 » 

Под win вообще не пишу. Компиляторы gcc или clang неплохо справляются с современными стандартами C/C++ и без проблем компилируют под amd64.

Необходимость в 64-битном коде на мой взгляд может быть в следующем:
1. ОС чисто 64 бита и никак иначе. Такое уже есть. Ну, тут и думать нечего.
2. Нужно использовать уже скомпиленные библиотеки под 64-битный код.
3. Есть нужда в выделении больших объемов памяти — более 2 ГБ на процесс. В противном случае будет экономичнее 32-битный код.
4. Тенденция. Если коду предстоит долгая служба, его стоит делать либо совместимым 32/64, либо сразу 64.

Установи 64-битный набор библиотек для рантайм и devel (там не только заголовки, но и линкующиеся части могут быть).
« Последнее редактирование: 27-01-2017 15:38 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 27-01-2017 16:28 » 

Установил MinGW из проекта TDM64: gcc (tdm64-1) 5.1.0. Собирает без проблем.

Про увеличение размера исполняемого файла я был в курсе, но не думал, что настолько - прирост в 163% получился. Зато по-современному.)

Мне теперь интересно: можно ли использовать этот комплект в качестве линковщика для NASM? И какие промежуточные форматы используются при компиляции в штатном х64 порядке?
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 27-01-2017 17:09 » 

Если nasm может производить объектные файлы, формата, поддерживаемого твоим линкером, то почему бы и нет.

$ nasm -v
NASM version 2.11.08 compiled on Jun 17 2015
$ nasm -hf
...
valid output formats for -f are (`*' denotes default):
  * bin       flat-form binary files (e.g. DOS .COM, .SYS)
    ith       Intel hex
    srec      Motorola S-records
    aout      Linux a.out object files
    aoutb     NetBSD/FreeBSD a.out object files
    coff      COFF (i386) object files (e.g. DJGPP for DOS)
    elf32     ELF32 (i386) object files (e.g. Linux)
    elf64     ELF64 (x86_64) object files (e.g. Linux)
    elfx32    ELFX32 (x86_64) object files (e.g. Linux)
    as86      Linux as86 (bin86 version 0.3) object files
    obj       MS-DOS 16-bit/32-bit OMF object files
    win32     Microsoft Win32 (i386) object files
    win64     Microsoft Win64 (x86-64) object files
    rdf       Relocatable Dynamic Object File Format v2.0
    ieee      IEEE-695 (LADsoft variant) object file format
    macho32   NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (i386) object files
    macho64   NeXTstep/OpenStep/Rhapsody/Darwin/MacOS X (x86_64) object files
    dbg       Trace of all info passed to output stage
    elf       ELF (short name for ELF32)
    macho     MACHO (short name for MACHO32)
    win       WIN (short name for WIN32)
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #4 : 27-01-2017 17:30 » 

Ну вот, как можно видеть есть формат: elf64, а есть win64. Для комбинацией с tcc я применял elf (elf32). Кстати, применение этих форматов не прозрачно, каждый требует определённых правил при написании asm кода.

Мне интересна последовательность в комплекте:
gcc преобразует (source.c + source.h) -> source.asm
as преобразует source.asm -> source.o
ld преобразует source.o -> source.exe

Таким образом, как я понимаю, соединять nasm и gcc нужно на этапе ld.
Соответственно:
GNU ld (GNU Binutils) 2.25

Выходные цели:
ld: supported targets: pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64
elf64-l1om elf64-k1om pe-i386 pei-i386 elf32-i386 elf64-little elf64-big elf32-little
elf32-big plugin srec symbolsrec verilog tekhex binary ihex

Как понимаю моё: pe-x86-64? (pei-x86-64?) Но могу ошибиться. И на вход ему можно что угодно или что-то конкретно?
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 27-01-2017 17:43 » 

Мне интересна последовательность в комплекте:
gcc преобразует (source.c + source.h) -> source.asm
as преобразует source.asm -> source.o
ld преобразует source.o -> source.exe

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

Цитата
Таким образом, как я понимаю, соединять nasm и gcc нужно на этапе ld.

А где ж еще...

Используй дефолтный формат. Не ломай голову там, где это можно не делать.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Aether
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #6 : 27-01-2017 17:47 » new

gcc -c -m64 -std=c99 source.c -o source.o
objdump -a source.o

source.o file format pe-x86-64

gcc -m64 -std=c99 source.c -o source.exe
objdump -a source.exe

source.exe file format pei-x86-64

Получается, что выходным должен быть pei-x86-64, а входным пока под вопросом.

Добавлено через 8 минут и 49 секунд:
И ещё вот какая тема: Windows при линковке должен получить информацию о том: консольное приложение или оконное, в общем, тоже есть ещё что почитать.

Используй дефолтный формат. Не ломай голову там, где это можно не делать.
Так и делаю, но тема про х64 уже всплывает не первый раз. Надо будет попробовать, к тому же посмотрел: в блоке РОН добавилось ещё 8 регистров, которые из х86 не доступны - R8 ... R15.
« Последнее редактирование: 27-01-2017 17:56 от Aether » Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines