[haker_fox 60]

1 minute ago, Tarbal said:

О! Я на РК86

Круто) А для меня те времена прошли лет на пять раньше по отношению к моему детствую и юности)

1 minute ago, Tarbal said:

Вот тогда 2 килобайтных 573РФ2 и 573РФ5 напрограммировал и настирал.

О да, эти микры не обошли меня стороной в далёком 2008 году. Когда нужно было восстановить старенькую систему управления промыленным роботом на базе PDP-11) Делал программатор для них на ATMega16 + расширитель портов К580ВВ55А)

[Tarbal 4]

1 minute ago, haker_fox said:

Круто) А для меня те времена прошли лет на пять раньше по отношению к моему детствую и юности)

О да, эти микры не обошли меня стороной в далёком 2008 году. Когда нужно было восстановить старенькую систему управления промыленным роботом на базе PDP-11) Делал программатор для них на ATMega16 + расширитель портов К580ВВ55А)

А что? 55 вполне неплохой интерфейс. Да и несложный, а 79й контроллер до сих пор в PCшках ставят. Потому и команда прерывания 0XCD, что это был код вызова подпрограммы в 8080, а контроллер вырабатывал код вызова подпрограммы, чтобы уйти на обработку прерывания.

[haker_fox 60]

13 minutes ago, Tarbal said:

55 вполне неплохой интерфейс.

Теперь мне кажется. что и весь 580-й комплекс был не очень сложным) На фоне современных SoC...

[Tarbal 4]

38 minutes ago, haker_fox said:

Теперь мне кажется. что и весь 580-й комплекс был не очень сложным) На фоне современных SoC...

Верно подмечено :)

[rkit 1]

1 hour ago, haker_fox said:

Что вы имеете в виду: какой компилятор, какие функции? Я использую IAR 8.40.1 и смотрел ассемблерный выхлоп для некоторых функций, вполне себе адекватный результат. При этом я не сторонник использования таких штук как std::string/vector/map.

#include <iostream>, например, сходу увеличивает бинарник на добрые 150кб. А вот с перечисленным, как раз, проблем нет, потому что это 1 в 1 аналог ручной реализации того же на С. И если хватает памяти для этого на С, то и на С++ всё в порядке.

Изменено 8 июня, 2021 пользователем rkit

[haker_fox 60]

2 minutes ago, rkit said:

#include <iostream>, например, сходу увеличивает бинарник на добрые 150кб.

Врунишка)))

2 minutes ago, rkit said:

А вот с перечисленным, как раз, проблем нет, если оперативки достаточно.

Проблем нет. Никаких. Просто я не сторонник использования. Т.к. время выполнения кода в моих приложениях критично. Хотя оперативка и есть. 32 Мб целых)

[rkit 1]

Знал ведь, что не стоит на этого поехавшего реагировать.

[haker_fox 60]

3 minutes ago, rkit said:

Знал ведь, что не стоит на этого поехавшего реагировать.

Я проверил ваше предположение. Вставил в свой проект #include <iostream>, скомпилировал проект. Никакого увеличения. Ни на байт. Может быть вы используете компилятор, который морально устарел?

[makc 192]

20 минут назад, haker_fox сказал:

Может быть вы используете компилятор, который морально устарел?

Может вы просто не поняли, что хотел сказать автор? Мне думается, что он имел в виду не только физическое включение заголовочного файла, но и использование его базового функционала, иначе зачем бы его нужно было включать. Вы же прицепились к словам "#include <iostream>" и сделали далеко идущие выводы.

[Сергей Борщ 119]

4 часа назад, Tarbal сказал:

Да и начинал я с такой мелочевки. На PIC16C71 вообще было 23 байта памяти данных.

Модератор: господа-товарищи! Если хотите (напишите в личку), я могу вынести вашу ностальгию в отдельную тему "бойцы вспоминают минувшие дни" и пишите там сколько угодно. Здесь же прошу все-таки придерживаться заданной автором темы.

17 минут назад, makc сказал:

Может вы просто не поняли, что хотел сказать автор?

Нет. Я сам лет восемь назад в gcc на PC наблюдал увеличение исполняемого файла на полтора мегабайта только от добавления строки #include  <iostream>. Проверил сейчас - +700 кБайт. Не сказал бы, что gcc 9.3.0 (такой стоит по-умолчанию в моем линксе) сильно устарел - ему всего два года. Ставить последний не буду, полагаю ситуация там не сильно отличается:

xxxxxxxxxxx/trunk/software/common/externals/pc_utils/bootloader/gentemp/pages$ make
Compiling: main.cpp
Compiling: ./../gentemp.cpp
Linking: release/gentemp

   text	   data	    bss	    dec	    hex	filename
 744233	  20540	   5712	 770485	  bc1b5	release/gentemp

// добавляем в main.cpp строку #include	<iostream>
xxxxxxxxxxx/trunk/software/common/externals/pc_utils/bootloader/gentemp/pages$ make
Compiling: main.cpp
Linking: release/gentemp

   text	   data	    bss	    dec	    hex	filename
1464397	  39228	  16568	1520193	 173241	release/gentemp

Меня тогда еще этот случай сильно заинтересовал и я покопался в листингах - вроде бы там все дело в конструкторах/деструкторах стандартных потоков.

[adnega 10]

Насчет #include  <iostream>:

- а от уровня оптимизации зависит увеличение размера?

- а map-файл показывает за счет чего размер вырос?

[haker_fox 60]

30 minutes ago, makc said:

Может вы просто не поняли, что хотел сказать автор?

Так я выше просил назвать конкретные функции для примера.

25 minutes ago, Сергей Борщ said:

Нет. Я сам лет восемь назад в gcc на PC

А для микроконтроллеров? У меня IAR ничего не тянет.

[Сергей Борщ 119]

3 минуты назад, haker_fox сказал:

А для микроконтроллеров?

xxxxxxxxxxxxxxxx/trunk/software/application$ make
Compiling: version.cpp
Compiling: main.cpp
Linking: release/xxxxxx_prototype.elf
Generating hex: release/xxxxxxx_prototype.hex
Generating disassembly: release/lst/xxxxxxx_prototype.lss

   text	   data	    bss	    dec	    hex	filename
  22868	      0	  14160	  37028	   90a4	release/xxxxxxx_prototype.elf

// добавляем в main.cpp строку #include	<iostream>
xxxxxxxxxxxxxxxx/trunk/software/application$ make
Compiling: version.cpp
Compiling: main.cpp
Linking: release/xxxxxx_prototype.elf
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: /opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc_nano.a(lib_a-snprintf.o): in function `snprintf':
snprintf.c:(.text.snprintf+0x0): multiple definition of `snprintf'; ./release/obj/sprintf.o:/home/xxxxxxxxxxxx_prototype/trunk/software/application/././../common/externals/lib/printf/sprintf.cpp:21: first defined here
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: /opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc_nano.a(lib_a-sscanf.o): in function `sscanf':
sscanf.c:(.text.sscanf+0x0): multiple definition of `sscanf'; ./release/obj/sscanf.o:/home/xxxxxxxxxxxx_prototype/trunk/software/application/././../common/externals/lib/sscanf/sscanf.cpp:439: first defined here
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: /opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc_nano.a(lib_a-strtol.o): in function `strtol':
strtol.c:(.text.strtol+0x0): multiple definition of `strtol'; ./release/obj/strtol.o:/home/xxxxxxxxxxxx_prototype/trunk/software/application/././../common/externals/lib/sscanf/strtol.cpp:119: first defined here
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: /opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libc_nano.a(lib_a-strtoul.o): in function `strtoul':
strtoul.c:(.text.strtoul+0x0): multiple definition of `strtoul'; ./release/obj/strtol.o:/home/xxxxxxxxxxxx_prototype/trunk/software/application/././../common/externals/lib/sscanf/strtol.cpp:208: first defined here
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: release/xxxxxx_prototype.elf section `.text' will not fit in region `TEXT'
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: release/xxxxxx_prototype.elf section `.bss' will not fit in region `RAM'
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: section .config VMA [000000000800fc00,000000000800fc1f] overlaps section .text VMA [0000000008002000,0000000008030bc7]
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: region `TEXT' overflowed by 135828 bytes
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 4392 bytes
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: ./release/obj/heap.o: in function `operator new(unsigned int)':
/home/xxxxxxxxxxxxxxxxxx_prototype/trunk/software/application/././../common/externals/lib/heap/heap.cpp:103: undefined reference to `free_memory()'
/opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: /opt/arm-gcc/2020-q4/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp/libnosys.a(sbrk.o): in function `_sbrk':
sbrk.c:(.text._sbrk+0x18): undefined reference to `end'
collect2: error: ld returned 1 exit status

Боюсь, у меня не хватит терпения писать заглушки на все функции, которые оно хочет и отучать использовать библиотечные snprintf, sscanf, strol, stroul вместо моих.

[haker_fox 60]

13 minutes ago, Сергей Борщ said:

Боюсь, у меня не хватит терпения писать заглушки на все функции

Спасибо за результат! Вот теперь и возникает вопрос к @rkit каким компилятором он компилировал для МК, чтобы получить 150 кБ лишка) Ведь для gcc ему бы пришлось писать заглушки, IAR вообще ничего не тащит. Кейл остаётся) Ну либо какой-то другой gcc...