On 26.08.2022 20:25, Atlantis wrote:
[...]
> Czy nie istnieje np. ryzyko, że kompilator spróbuje to niejawnie
> zoptymalizować i zdefiniuje sobie we flashy łańcuchu "Lights ", "on"
> oraz "off", a potem będzie tworzył ich kombinacje na stosie, przed
> przekazaniem w argumencie funkcji?
Skompiluj sobie do assemblera z parametrem -fverbose-asm np. taki programik:

===================== CIĄĆ TUTAJ=========================
void send(const char* str);

const int x = 5;
const int a;

int main(int argc, char *argv[])
{
const int y = 7;
static const int z = 8;
const char *s = "dupa";
const int t[] = {1, 2, 3, 4, 5};

send("Lights on");
send("Lights off");

return 0;
}
===================== CIĄĆ TUTAJ=========================

Np. w przypadku ARM-a wychodzi coś takiego:

===================== CIĄĆ TUTAJ=========================
.cpu arm7tdmi
.arch armv4t
.fpu softvfp
.eabi_attribute 20, 1 @ Tag_ABI_FP_denormal
.eabi_attribute 21, 1 @ Tag_ABI_FP_exceptions
.eabi_attribute 23, 3 @ Tag_ABI_FP_number_model
.eabi_attribute 24, 1 @ Tag_ABI_align8_needed
.eabi_attribute 25, 1 @ Tag_ABI_align8_preserved
.eabi_attribute 26, 1 @ Tag_ABI_enum_size
.eabi_attribute 30, 6 @ Tag_ABI_optimization_goals
.eabi_attribute 34, 0 @ Tag_CPU_unaligned_access
.eabi_attribute 18, 4 @ Tag_ABI_PCS_wchar_t
.file "testargt.c"
@ GNU C17 (GNU Toolchain for the Arm Architecture 11.2-2022.02
(arm-11.16)) version 11.2.1 20220111 (arm-none-eabi)
@ compiled by GNU C version 7.3-win32 20180312, GMP version 6.2.1, MPFR
version 3.1.6, MPC version 1.0.3, isl version isl-0.15-1-g835ea3a-GMP

@ GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
@ options passed: -mcpu=arm7tdmi -mfloat-abi=soft -marm -march=armv4t
.text
.global x
.section .rodata
.align 2
.type x, %object
.size x, 4
x:
.word 5
.global a
.align 2
.type a, %object
.size a, 4
a:
.space 4
.align 2
LC0:
.ascii "dupa\000"
.align 2
LC1:
.ascii "Lights on\000"
.align 2
LC2:
.ascii "Lights off\000"
.text
.align 2
.global main
.syntax unified
.arm
.type main, %function
main:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 1, uses_anonymous_args = 0
push {fp, lr} @
add fp, sp, #4 @,,
sub sp, sp, #16 @,,
str r0, [fp, #-16] @ argc, argc
str r1, [fp, #-20] @ argv, argv
@ testargt.c:8: const int y = 7;
mov r3, #7 @ tmp115,
str r3, [fp, #-8] @ tmp115, y
@ testargt.c:10: const char *s = "dupa";
ldr r3, .L3 @ tmp116,
str r3, [fp, #-12] @ tmp116, s
@ testargt.c:13: send("Lights on");
ldr r0, .L3+4 @,
bl send @
@ testargt.c:14: send("Lights off");
ldr r0, .L3+8 @,
bl send @
@ testargt.c:16: return 0;
mov r3, #0 @ _6,
@ testargt.c:17: }
mov r0, r3 @, <retval>
sub sp, fp, #4 @,,
@ sp needed @
pop {fp, lr} @
bx lr @
L4:
.align 2
L3:
.word .LC0
.word .LC1
.word .LC2
.size main, .-main
.section .rodata
.align 2
.type t.0, %object
.size t.0, 20
t.0:
.word 1
.word 2
.word 3
.word 4
.word 5
.align 2
.type z.1, %object
.size z.1, 4
z.1:
.word 8
.ident "GCC: (GNU Toolchain for the Arm Architecture 11.2-2022.02
(arm-11.16)) 11.2.1 20220111"
===================== CIĄĆ TUTAJ=========================

Jak widać, stringi lądują w sekcji .rodata (czasami nazywanej też
rdata), która w przypadku systemów embedded zazwyczaj jest umieszczana
we Flashu (aczkolwiek ktoś na starcie systemu może chcieć skopiować ją
do SRAM, bo odczyty z SRAM są szybsze). I tak jest ,,wszędzie". Natomiast
const-y ,,typów prostych" zazwyczaj również lądują w .rodata, ale nie
zawsze - na ARM (jak widać) czy na x86-64 tak, ale na MIPS już nie
(tutaj w sekcji .sdata - ,,small data").

Powyższe dotyczy oczywiście jedynie słusznego kompilatora, czyli gcc.