Иногда возникает ситуация, когда надо что‑то посчитать согласно сложному алгоритму прямо на LapTop/NetTop/DeskTop PC. При этом этот алгоритм написан на Си. Это может быть цифровой фильтр, дискретное преобразование Фурье, генератор QR кода, кусок линейной алгебры с векторами, какое‑то тригонометрическое вычисление, программный модулятор, статистическая обработка случайной величины. Да всё, что угодно! То есть Вы хотите использовать язык Си как гибкий и быстрый калькулятор в Windows. Тут надо написать программу на Си.

Компьютер — это универсальный вычислитель

Или, например, Вы программируете микроконтроллеры на Си и хотите сделать симулятор прошивки в виде консольного приложения. Надо вам, например, прогнать модульные тесты платформа‑независимого кода на «большом компьютере». Потом Вам 80% вероятность, что понадобится конфигуратор прошивки по UART. Потом Вам понадобится консольное приложение Loader для загрузки по UART самой прошивки через BootLoader.

Потом понадобится крохотная PC‑утилита синхронизации для часов реального времени с PC.

Почему именно Си?

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

  2. Дело в том что язык программирования Си — это самый простой язык программирования из тех, что всё еще более или менее используется в промышленной разработке. По факту в Си только функции и переменные. Тут нет никаких виртуальных функций, шаблонов, делегатов и прочих концепций. В Си всё предельно просто и конкретно.


Разработка под PC это не сross компиляция, как в случае со сборкой артефактов для микроконтроллера, и тут в PC всё в какой‑то степени проще. При сборке Си приложения не надо думать о файле конфигурации компоновщика, как мы это привыкли делать для cross компиляции артефактов для микроконтроллеров (файлы *.ld).

Сперва определимся для какого Target(а) надо собрать бинарь. Надо узнать какой у нас на материнской плате установлен микропроцессор. Такую информацию может показать утилита CPUZ.

В данном случае у меня на одном компьютере Intel Celeron J4125 2Ghz, 4x cores, L1 32kByte, L2 4MByte, 10W. На другом компьютере установлен 64 разрядный микропроцессор AMD Ryzen 5 PRO 3400GE 3.30 GHz.

Но это даже не так важно. Важно какой у нас Instruction Set. В данном случае — x86–64. Это значит, что у нас 64-битный процессор. Получается, что у нас есть выбор: либо ставить 64-битный компилятор Си, либо накатывать 32-битный компилятор Си.

Как правило, нам приходится работать на разных процессорах, однако мы в OS Windows этого даже не замечаем.

Units:

text

bit

N

N

kByte

kByte

MByte

Процессор

bitness

cores

Threads

L1

L2

L3

1

AMD Ryzen 5 PRO 3400GE

64

4

8

32

512

4

2

Intel Celeron J4125

4

4

32

3

Intel Core i7 8550U

64

4

8

32

256

8

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

Как и в любом деле сначала надо определится с терминологией.

Терминология

Компилятор — программа, переводящая написанный на языке программирования читаемый понятный человеком текст, в набор машинных кодов (человеко‑нечитаемый бинарный код). Программисты это люди, которые как никто приближены к абстракциям. Любой язык программирования, в частности Си — это уровень на коротком можно не думать о наборе команд данного микропроцессора. У процессора нет никаких переменных и функций. Переменные существуют только в сознании программиста. Поэтому нам нужен компилятор Си. Компилятор для каждого Cи файлика производит *.o файлик с родным для данного процессора машинным кодом.

Компоновщик (Linker)— утилита, которая склеивает бинарные файлы *.o в один монолитный исполняемый бинарный файл программы. В нашем случае это *.exe.

Артефакт — результат работы ToolChain(а). В нашем случае это *.exe файл с бинарным файлом программы.

Что надо из софтвера?

Текстовый редактор (Text Editor)

Прежде всего нужен какой‑то текстовый редактор, чтобы написать этот самый исходный текст программы на Си. Тут вариантов масса. NotePad++, Eclipse, MS VS Code.

Сборщик (Build Tools)

В компьютерах ничего само собой не происходит. Компьютеры - это самые ленивые и безынициативные сущности. Им всё надо объяснять максимально подробно и понятно. Поэтому надо явно указать из каких *.с файлов мы хотим собирать программу. Эти файлы надо как-то перечислить проиндексировать. Для этого была создана специальная утилита называемая make. Идея проста. Создается текстовый файл (Makefile) и в нем прописывается правильная последовательность вызова консольных утилит, которая приведет к тому, что на жестком диске появится исполняемый файл с программой.

Препроцессор (Preprocessor)

Это такая консольная утилита (cpp.exe), которая вставляет и заменяет куски текста. Нужна чисто ради удобства написание текста. Препроцессор позволяет полностью исключить такое нехорошее явление как дублирование программного кода. При этом препроцессору абсолютно всё равно с каким языком программирования работать (Cи, C++, DeviceTree, Graphviz, скрипты компоновки и т. п.). Для препроцессора любой язык программирования - это просто текст.

Теперь рассмотрим практические аспекты.

Какой выбрать компилятор Си кода?

Тут есть несколько бесплатных вариантов на выбор.

Компилятор

разрядность генерируемого кода

1

СygWin

64

2

MinGW

32

3

Mingw-w64

64

4

clang

64

5

Tiny C Compiler

32/64

Для программистов микроконтроллеров я настоятельно рекомендую выбрать именно MinGW. Дело в том, что MinGW генерирует 32-битный код. Это как раз соответствует тому, что большинство микроконтроллеров (например ARM Cortex Mx) как раз 32-битные. И Вы так достигните большей совместимости между кодом прошивки микроконтроллера и консольным приложением в Windows.

Вторая причина по которой надо использовать компилятор C:\MinGW\bin\gcc.exe заключается в том, что в окружении MinGW есть заголовочный файл conio.h, который определяет функцию kbhit(). Это нам понадобится для имитации на PC текстового терминала UART-CLI консоли в stdout/stdin.

>C:\MinGW\bin\gcc.exe  --version
gcc.exe (MinGW.org GCC-6.3.0-1) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Набор утилит MinGW преспокойно скачивается и устанавливается как любая другая программа под OS Windows.

Компоновщик (Linker)

Компоновкой занимается утилита ld, которая вызывает collect2. Именно утилита collect2.exe будет выдавать ошибки, если Вы будите вызывать функции без определения их тела.

Что вообще надо из софтвера?

Вот минимальный джентельменский набор для того чтобы собрать программу на Си.

Назначение утилиты

Название утилиты

1

Текстовый редактор

NotePad++.exe

2

Препроцессор

cpp.exe

3

Компилятор

gcc.exe

4

Консольная утилита для удаления файлов или папок

rm

5

Компоновщик

ld.exe

6

Утилита управления ToolChain(ом). Она решает что и в какой последовательности собирать, чтобы получить артефакты

make.exe

7

Утилита анализа получившегося бинаря. Аналог readelf.exe из мира программирования микроконтроллеров

PE explore.exe

Традиционно программы на Си собирают из make скриптов. Вот минималистический makefile для сборки много файлового Си‑проекта на Windows

MK_PATH:=$(dir $(realpath $(lastword $(MAKEFILE_LIST))))
#@echo $(error MK_PATH=$(MK_PATH))
INCDIR += -I$(MK_PATH)

WORKSPACE_LOC:= $(MK_PATH)../../
$(info  WORKSPACE_LOC= $(WORKSPACE_LOC))
INCDIR += -I$(WORKSPACE_LOC)

BUILDDIR := $(MK_PATH)/Build

SRC_PATH :=  $(dir $(abspath $(dir $$PWD) ))
#@echo $(error SRC_PATH=$(SRC_PATH))

OBJDIR := $(SRC_PATH)obj
# the compiler to use

OPT += -DHAS_GCC
CC = C:\MinGW\bin\gcc.exe

# compiler flags:
#  -g    adds debugging information to the executable file
#  -Wall turns on most, but not all, compiler warnings
CFLAGS += -g

#Generate code for 32-bit ABI
CFLAGS += -m32

CFLAGS += -std=c11 -fshort-enums
#CFLAGS += -Og
CFLAGS  += -O0
#CFLAGS  += -Wall
#CFLAGS  +=-pedantic
#CFLAGS += -ftime-report

#files to link:
LFLAGS += -static
#LFLAGS += -lm

EXECUTABLE=firmware_simulator_x86_m

include $(MK_PATH)config.mk

ifeq ($(CLI),Y)
    include $(MK_PATH)cli_config.mk
endif

ifeq ($(UNIT_TEST),Y)
    include $(MK_PATH)test_config.mk
endif

ifeq ($(UNIT_TEST),Y)
    include $(MK_PATH)diag_config.mk
endif

include $(WORKSPACE_LOC)code_base.mk


#@echo $(error SOURCES_C= $(SOURCES_C))
INCDIR := $(subst /cygdrive/c/,C:/, $(INCDIR))
#@echo $(error INCDIR= $(INCDIR))
OBJ := $(patsubst %.c, %.o, $(SOURCES_C))
OBJ := $(subst /cygdrive/c/,C:/, $(OBJ))
#@echo $(error OBJ= $(OBJ))

.PHONY:all

all:$(OBJ) $(EXECUTABLE)

$(EXECUTABLE): $(OBJ)
	$(CC) $(CFLAGS)  $(OBJ) $(LFLAGS) -o $(EXECUTABLE).exe 

%.o: %.c
	$(CC) $(CFLAGS) $(INCDIR) $(OPT) -c $< -o $@ 

clean:
	rm -r $(EXECUTABLE) $(OBJ) 

Тут файлы config.mk, cli_config.mk, test_config.mk и diag_config.mk это просто файлы с перечислением набора переменных окружения для выборочной сборки конкретных исходников из общей кодовой базы. Вот корневой makefile для подключения разных программных компонентов code_base.mk

ifneq ($(CODE_BASE_MK),Y)
    CODE_BASE_MK=Y
    $(info CodeBase Config)

    #@echo $(error WORKSPACE_LOC=$(WORKSPACE_LOC))
    INCDIR += -I$(WORKSPACE_LOC)

    ifeq ($(THIRD_PARTY),Y)
        include $(WORKSPACE_LOC)/third_party/third_party.mk
    endif

    ifeq ($(APPLICATIONS),Y)
        include $(WORKSPACE_LOC)/applications/applications.mk
    endif

    ifeq ($(CONNECTIVITY),Y)
        include $(WORKSPACE_LOC)/connectivity/connectivity.mk
    endif

    ifeq ($(CONTROL),Y)
        include $(WORKSPACE_LOC)/control/control.mk
    endif
    
    ifeq ($(COMPUTING),Y)
        #@echo $(error COMPUTING=$(COMPUTING))
        include $(WORKSPACE_LOC)/computing/computing.mk
    endif

    ifeq ($(SENSITIVITY),Y)
        #@echo $(error SENSITIVITY=$(SENSITIVITY))
        include $(WORKSPACE_LOC)/sensitivity/sensitivity.mk
    endif

    ifeq ($(STORAGE),Y)
        #@echo $(error STORAGE=$(STORAGE))
        include $(WORKSPACE_LOC)/storage/storage.mk
    endif

    ifeq ($(UNIT_TEST),Y)  
        include $(WORKSPACE_LOC)/unit_tests/unit_test.mk
    endif
endif

Конечный make файл может выглядеть например так. Вот тут и индексируют конечные *.c файлы и определяют ключевые слова для препроцессора (начинаются на HAS_XXXXX).


$(info SCHMITT_TRIGGER_MK_INC=$(SCHMITT_TRIGGER_MK_INC))
ifneq ($(SCHMITT_TRIGGER_MK_INC),Y)
    SCHMITT_TRIGGER_MK_INC=Y

    mkfile_path := $(abspath $(lastword $(MAKEFILE_LIST)))
    $(info Build  $(mkfile_path) )

    SCHMITT_TRIGGER_DIR = $(COMPUTING_DIR)/schmitt_trigger

    INCDIR += -I$(SCHMITT_TRIGGER_DIR)
    SOURCES_C += $(SCHMITT_TRIGGER_DIR)/schmitt_trigger.c

    SCHMITT_TRIGGER=Y
    OPT += -DHAS_SCHMITT_TRIGGER

    ifeq ($(DIAG),Y)
        OPT += -DHAS_SCHMITT_TRIGGER_DIAG
        SOURCES_C += $(SCHMITT_TRIGGER_DIR)/schmitt_trigger_diag.c
    endif

    ifeq ($(CLI),Y)
        ifeq ($(SCHMITT_TRIGGER_COMMANDS),Y)
            OPT += -DHAS_SCHMITT_TRIGGER_COMMANDS
            SOURCES_C += $(SCHMITT_TRIGGER_DIR)/schmitt_trigger_commands.c
        endif
    endif
endif

Если говорить метафорично, то Make - это как механическая коробка передач, только для сборки программ. C Make Вы можете буквально контролировать каждую опцию компилятора.

При первой сборке проекта скорее всего выскочит вот эта ошибка. Это значит, что надо переустановить MinGW.


C:\Users\username\AppData\Local\Temp\ccT9XWou.s:54: Error: invalid instruction suffix for `push'
C:\Users\username\AppData\Local\Temp\ccfvWBon.s:19: Error: invalid instruction suffix for `pop'

Надо чтобы команда gcc.exe -dumpmachine после установки показывала mingw32

>C:\MinGW\bin\gcc.exe -dumpmachine
mingw32


Содержимое того Makefile можно представить в виде вот этой простенькой блок схемы ToolChain(а). Тут можно визуально проследить какой путь проходит *.с файл с момента написания до исполнения в Windows.

Схема ToolChain(а) для сборки Си кода
Схема ToolChain(а) для сборки Си кода

В остальном сборка на PC не отличается от сборки для микроконтроллера. В этом и достоинство сборки из Make. При работе с make cборка под любые процессоры выглядит плюс/минус одинаково. Просто по другому определенные переменные окружения: CC LD и т. п. Все те же *.mk файлы подтянутся что и в кодовой базе для прошивок.

Про то как происходит сборка прошивок из-под скриптов можно почитать в этом тексте:
Настройка ToolChain(а) для Win10+GCC+С+Makefile+ARM Cortex-Mx+GDB.

Когда собралась вся кодовая база бинарь получился всего 1,9MByte

Отладка имитатора прошивки

Артефактом сборки является файл *.exe. Его можно запустить вызвав его из командной строки cmd.

Тут происходит имитация UART-CLI терминала только вместо UART выступают файлы stdin (аналог UART-RX)/stdout (аналог UART-TX).

Можно заметить, что скорость исполнения приложения просто бешеная. За одну секунду супер-цикл успевает прокрутиться аж 11 240 590 раз! В микроконтроллерах это значение обычно было порядка 7588 раз.

диагностика супер цикла в микроконтроллере ARM Cortex-M33
диагностика супер цикла в микроконтроллере ARM Cortex-M33

Получается, что на PC приложение исполняется быстрее в 1481 раз. На три порядка быстрее!

диагностика супер цикла в консольном приложении Win32
диагностика супер цикла в консольном приложении Win32

Вывод

Сборка кода на Cи для DeskTop это весьма полезный навык при отладке микроконтроллерных прошивок. Можно отладить огромные куски платформа независимого кода: CRC, обработку строчек, триггер Шмитта, бинарные протоколы, и т.п.

Также можно собрать проект разными компиляторами: GCC, Clang. И тем самым найти и устранить больше ошибок в кодовой базе.

Как видите, в сборке Си программ на PC, ровным счетом, нет ничего сложного. Надеюсь этот текст поможет большему количеству программистов-микроконтроллеров отлаживать свои приложения на DeskTop PC и создавать, тем самым, отличные программные продукты.

Links

Компилятор GCC. Первая программа на Windows

EclipseIDE.Установка, настройка, программирование на С/Installation, configuration, programming in C

Eclipse и MinGW: как указать IDE путь к makefile и файлам проекта; разделение mingw32-make и ключей

MinGW - Minimalist GNU for Windows

Генерация зависимостей внутри программы

Сборка firmware для CC2652 из Makefile

Почему Важно Собирать Код из Скриптов

Настройка ToolChain(а) для Win10+GCC+С+Makefile+ARM Cortex-Mx+GDB

Tiny C Compiler - Summary https://savannah.nongnu.org/projects/tinycc

The LLVM Compiler Infrastructure https://llvm.org/

Вопросы

  1. Какой путь проходит с файл с момента написания до момента исполнения?

  2. Что происходит между нажатием на Enter при запуске консольной утилиты в cmd и запуском функции main()?

Комментарии (49)


  1. IlyaDatsiuk
    11.12.2023 21:58

    Проще установить unix подобную систему и писать программы на С под неё. (Моё мнение))


    1. aabzel Автор
      11.12.2023 21:58

      В Linux я не находил нормальной утилиты для сравнения текстовых файлов, которая по удобству хотя бы близко могла приблизится к WinMerge.exe.


      1. lorc
        11.12.2023 21:58

        meld?


      1. Gumanoid
        11.12.2023 21:58

        vimdiff?


        1. aabzel Автор
          11.12.2023 21:58

          vimdiff - самый худший diff tool, который я когда-либо видел


          1. Gumanoid
            11.12.2023 21:58

            Вроде всё наглядно и удобно. Только цветовую тему я бы сменил на менее кислотную, типа:


      1. SpiderEkb
        11.12.2023 21:58

        В Linux у вас уже будет "нативный" gcc.

        Вы можете поставить любую IDE - хоть VSCode, хоть CodeBlocks, хоть CodeLite (тут, кстати, вам не придется писать make файлы - оно само это будет за вас делать - просто создаете и конфигурируете проект - достаточно компактная и удобная среда для небольших проектов, под винду, кстати, тоже есть).

        И аналог WinMerge тут, как правильно заметили, есть - Meld.

        В качестве файлового менеджера - привычный по винде DoubleCommander.


      1. ncpuma
        11.12.2023 21:58

        kdiff3?


  1. codecity
    11.12.2023 21:58

    А почему не использовать CMake?


    1. aabzel Автор
      11.12.2023 21:58

      Make как-то ближе к физике процесса.
      После микроконтроллеров осталась привычка к Low Level.


      1. Sazonov
        11.12.2023 21:58

        Что вы подразумеваете под low level в системах сборки? Low level код это понятно.


        1. aabzel Автор
          11.12.2023 21:58

          CMake при определенной настройке генерит make скрипты.
          CMake это по сути надстройка над make.
          Вот и получается что make - low level; CMake - hi level.


          1. Sazonov
            11.12.2023 21:58

            Вы фантазируете. Cmake это не надстройка на make. Make это лишь из один возможных форматов выхлопа. Make не используется самим Cmake, это опция. Это как сказать что велосипед это бэкэнд велозавода.


            1. awoland
              11.12.2023 21:58

              cmake на основе собственных описаний (CmakeList.txt) генерирует целевой проектный файл. Может по заказу сгенерировать GNU Makefile или Microsoft NMake Makefile. Может Visual Studio Solution или Apple Xcode projects... Далее полученый проект обрабатывается соостветствующим билдером. В случае GNU Makefile будет нужен GNU make. Make не используется самим cmake, но для дальнейшей сборки с использованием Makefile он необходим. Получается в пайплайне сборки cmake является конвейерной надстройкой над make.


              1. Sazonov
                11.12.2023 21:58

                Ну как бы логично что если вы хотите использовать make, то вам нужен Makefile. Только как это относится к CMake?


    1. aabzel Автор
      11.12.2023 21:58

      Make дает больший контроль над ситуацией.
      Make - это как механическая коробка передач, a CMake - автомат.


  1. iggr63
    11.12.2023 21:58

    А был еще и nmake


  1. Cels
    11.12.2023 21:58

    del


  1. Wolf4D
    11.12.2023 21:58

    Не очень понял смысл статьи. Это литературный эксперимент?

    Ведь обучение Си обычно и начинается с того, что начинающий программист сначала пишет свои первые программы в простой "песочнице" PC, где ни о каких ограничениях платформы можно не думать. И когда он наберёт опыта работы с МК - он тем более будет знать простые вещи типа "как скомпилировать свой код". В итоге статья читается как высоконаучное описание "как ковырять в носу для чайников, на примере поз из йоги, базовая теория и основные подходы" :)

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

    Знаю случай, когда на МК и на ПК на том же коде отличались некоторые результаты операций деления. С имитацией этого народ знатно помучился.


    1. kipar
      11.12.2023 21:58

      Забавно, я на Си первые программы как раз для микроконтроллеров писал, потому что на работе решили МК заняться. Для програмирования на компе у меня дельфи был.

      Счас мне правда статья уже бесполезна, т.к. mingw-w64 уже себе настроил.


      1. Rusrst
        11.12.2023 21:58

        Ну это прям максимально странно, если честно. Потому что изучать си на МК, это то ещё занятие...


        1. aabzel Автор
          11.12.2023 21:58

          Ничего странного.
          Cи как язык программирования кроме микроконтроллеров больше никому, по большому счету, и не нужен!
          Более того всё чаще и чаще для программирования MCUшек применяют уже С++ .


          1. Rusrst
            11.12.2023 21:58

            Безотносительно нужности его на ПК (о чем тоже можно поспорить на самом деле) программирование под МК имеет кучу особенностей. И чтобы собрать хоть как-то рабочий код (который не будет черным ящиком как Ардуино, а действительно обучающим примером) надо неплохо так поразбираться во внутрянке (один header файл регистров будет тем ещё приключением). Это банально не самый удобный инструмент просто. Поэтому и учить на МК странно.


        1. kipar
          11.12.2023 21:58

          Надо было запилить проект на МК. Опытный советчик сказал - ну вам год надо архитектуру арм сначала изучать, но мы его не послушали. На чем его можно программировать - на ассемблере и на си. Ассемблер изучать долго, а нам надо проект делать. Значит си. Я про него что-то слышал в детстве, о вот и книжка Кернигана нашлась, почитал и погнали. Больше всего проблем было с тем чтобы Ethernet поднять (на отладочной плате и соответственно работающем примере был один чип phy, а на той что мы запилили - другой), а си - ну язык как язык, что-то похуже чем в дельфи что-то получше.


          1. aabzel Автор
            11.12.2023 21:58

            Для запуска TCP IP на микроконтроллере надо подключить код, который называется LwIP.


            1. kipar
              11.12.2023 21:58

              это да. Правда в тот раз я uIP использовал (более легковесная версия от того же автора). Проблема была с более низким уровнем - инициализацией PHY. Там надо подключиться к чипу и установить mac адрес для фильтрации пакетов, ну и у этих чипов слегка различался протокол.


              1. aabzel Автор
                11.12.2023 21:58

                Проблема была с более низким уровнем - инициализацией PHY.


                Написать драйвер для MDIO чипа это хорошо формализованная задача.
                Вот даже методичка есть.
                https://habr.com/ru/articles/683762/


                1. kipar
                  11.12.2023 21:58

                  я на си то второй раз в жизни писал, какие еще драйвера. Был рабочий пример, причем казалось что он и на этом чипе работал (просто задание мак адреса втихую не работало и он оставался дефолтный). Проблемы начинались когда два девайса в одну сеть подключали. Решилось парой дефайнов (PHY_ADDRESS и что-то там еще, дело было лет 15 назад).


  1. kovserg
    11.12.2023 21:58

    Иногда возникает ситуация, когда надо что-то посчитать согласно сложному алгоритму прямо на LapTop/NetTop/DeskTop PC

    Есть же простой вариант:
    C: tcc + st
    VHDL: ghdl + gtkwave + make + st

    ps: для дифов meld и beyond compare


    1. aabzel Автор
      11.12.2023 21:58


      1--Tiny C Compiler не может собрать эту функцию

      2--TCC не видит #include <complex.h>

      3--TCC ругается на определение типа внутри for

          for(uint8_t bit = 0U; bit <= 7U; bit++) {
      
          }

      4-- TCC не знает макроса

      __TIMESTAMP__

      5-- tcc: undefined symbol 'strlen' 'snprintf' 'fprintf' 'strdup' 'memcpy' 'free' 'calloc' 'write' 'memset' 'malloc' '__imp__iob' 'exit' 'tolower' 'strchr' '__mb_cur_max' '_pctype' '_isctype' 'srand' 'rand' 'qsort' 'strcpy' 'printf' 'strcasecmp' 'fabs' 'strncpy' 'sprintf' 'kbhit' '_getch' 'strcmp' 'fopen' 'fclose' 'abs' 'system' '_GetStdHandle@4' '_GetConsoleMode@8' '_SetConsoleMode@8' 'time' 'pow' 'sin' 'cos' 'sqrt' 'atan2' 'fmodf' 'fmod' 'acos' 'atan' 'strstr' '__fpclassifyf' 'memmove' 'strspn' 'strcspn' 'toupper' 'fgets' 'localtime' 'mktime' 'difftime' 'ftime' 'asctime' 'clock' 'gmtime' 'getc' 'fseek' 'ftell' 'fread' 'strncmp' 'memcmp' 'sscanf' '__imp__HUGE' 'putchar' 'puts' 'fabsf' 'fmaxf' 'fmax' '_controlfp' '__set_app_type' '__getmainargs'


    1. aabzel Автор
      11.12.2023 21:58

      Что-то компилятор TCC не может собрать даже math.h
      C:/tcc/include/math.h:217: error: unknown constraint 't'


      1. kovserg
        11.12.2023 21:58

        1. не используйте static при определение параметров: static void s20_rowround(int y[16]);

        2. да complex.h у него нет. но это не мешает проводить любые вычисления.

        3. у меня не ругается

        4. да такого макроса у него нет. (вам никто не мешает его определить в параметрах при компиляции)

        5. такое тоже не воспоизводится

        6. да там хедеры от gcc. Если вы будете испольтовать fabs то всё работает. Но если всё же хочется fabsf, fabsl и т.п. поменяйте в хедере "=t" на "=r" и оно заработает.

          st
          st


        1. aabzel Автор
          11.12.2023 21:58

          Какую Вы используете libc при сборке компилятором TCC?


          1. kovserg
            11.12.2023 21:58

            32х-битную


            1. aabzel Автор
              11.12.2023 21:58

              Это понятно. Интересует по какому адресу URL на диске лежит xxxlibc для TCC?


              1. kovserg
                11.12.2023 21:58

                там же в директории lib

                libtcc1-32.a
                msvcrt.def -- вот эту libc он и использует msvcrt.dll


  1. gdt
    11.12.2023 21:58

    По-моему Visual Studio имеет community edition и в ней можно писать в том числе и на C.


    1. kovserg
      11.12.2023 21:58

      Конечно умеет. Но на флешке таскать visual studio как-то не очень. Да и проще нажать ctrl+b и сразу увидить результат, чем колупаться с настройками проекта в gui.


      1. Wolf4D
        11.12.2023 21:58

        На флешке можно таскать портабельную сборку Qt Creator с MinGW, GDB, CMake и Qt 5. Я так и делаю, воткнулся, скопировался - и за 5 минут у тебя готова среда для разработки несложных приложений.


  1. Polarisru
    11.12.2023 21:58

    А почему нельзя взять Codeblocks, где все это работает из коробки, причем под Linux выглядит точно так же?


    1. aabzel Автор
      11.12.2023 21:58

      Хороший вопрос!

      Codeblocks - это IDE.
      Отсюда все проблемы связанные с IDE.
      Прежде всего это бесконечное дублирование конфигов для разных сборок в IDEшной xml.

      Подробнее про это тут
      https://habr.com/ru/articles/723054/


  1. GBR-613
    11.12.2023 21:58

    Нормальный IDE это возможность нормального дебаггирования. Неужели ради этого не стоит сконфигурировать GUI?


    1. aabzel Автор
      11.12.2023 21:58

      Пошаговую отладку кода можно и из консоли делать.

      Вот методичка для микроконтроллерных прошивок https://habr.com/ru/articles/694708/

      Для PC консольный GDB еще проще.


    1. aabzel Автор
      11.12.2023 21:58

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

      https://habr.com/ru/articles/698092/


      1. Polarisru
        11.12.2023 21:58

        Да-да, все так и есть, только модульные тесты спасут от необходимости интеграционного тестирования!


  1. Pitkin_zadov
    11.12.2023 21:58

    По моему у автора "заскок" на Make. У него все статьи этому посвящены.
    Автор, да все кто в теме, знают как, когда и чем лучше. Ваше навязывание "мейка" кажется уж слишком назойливым.
    Открываешь вроде интересную статью (по названию), а там опять "мейк".


    1. aabzel Автор
      11.12.2023 21:58

      А Вы чем собираете?


      1. kuzulis
        11.12.2023 21:58

        Все нормальные люди собирают при помощи Qbs


        1. lorc
          11.12.2023 21:58

          А я думал - build.sh :)