почему char занмает 4 байта памяти, Keil, LPC2106 Опции

[Kail]

компилятор Keil
char p[16] - занимает 64 байта памяти. Смотрел в дебагере симулятора. Почему? Куда копать? В сторону aligment?

И еще вопросики про память в догонку.
У меня стек в режиме User 0x400, т.е. 1024 байт, а я объявляю int p[1000], т.е. получится 4000 байт и потом в цикле заполняю массив for (i=0;i<1000;i++)p[i]=i; симулятор доходит до p[256] и все, дальше цикл крутится, но элементы не изменяют знвчения. Вопрос, почему не генерируются ошибки доступа к памяти?
Еще один вопрос, почему стэк растет вверх? Объявляю int i; и вижу ассемблерный код STMDB R13!,[R14], после его выполнения регистр свяи содержит значение 0x400003fc (при вершине стэка 0x40000400). Почему растет вверх, а не вниз???
UND_Stack_Size EQU 0x00000004
SVC_Stack_Size EQU 0x00000004
ABT_Stack_Size EQU 0x00000004
FIQ_Stack_Size EQU 0x00000004
IRQ_Stack_Size EQU 0x00000080
USR_Stack_Size EQU 0x00000400

AREA STACK, DATA, READWRITE, ALIGN=2
DSB USR_Stack_Size ; Stack for User/System Mode
DSB SVC_Stack_Size ; Stack for Supervisor Mode
DSB IRQ_Stack_Size ; Stack for Interrupt Mode
DSB FIQ_Stack_Size ; Stack for Fast Interrupt Mode
DSB ABT_Stack_Size ; Stack for Abort Mode
DSB UND_Stack_Size ; Stack for Undefined Mode
Top_Stack:

[aaarrr]

компилятор Keil
char p[16] - занимает 64 байта памяти. Смотрел в дебагере симулятора. Почему? Куда копать? В сторону aligment?

Посмотрите лучше, что написано в map-файле.

У меня стек в режиме User 0x400, т.е. 1024 байт, а я объявляю int p[1000], т.е. получится 4000 байт и потом в цикле заполняю массив for (i=0;i<1000;i++)p[i]=i; симулятор доходит до p[256] и все, дальше цикл крутится, но элементы не изменяют знвчения. Вопрос, почему не генерируются ошибки доступа к памяти?

А кто, по-вашему, должен сгенерировать ошибку, и почему?

Еще один вопрос, почему стэк растет вверх? Объявляю int i; и вижу ассемблерный код STMDB R13!,[R14], после его выполнения регистр свяи содержит значение 0x400003fc (при вершине стэка 0x40000400). Почему растет вверх, а не вниз???

Ассемблерный код STMDB R13!,[R14] сохраняет в стеке значение LR, и к int i никакого отношения не имеет. И где это стек "растет вверх"???

AREA STACK, DATA, READWRITE, ALIGN=2

Для стека ALIGN должен быть 4.

[Alexey Bishletov]

AREA STACK, DATA, READWRITE, ALIGN=2

Для стека ALIGN должен быть 4.

ALIGN=2 это видимо и есть 4, т.е. выравнивание 2 в степени (ALIGN)

[aaarrr]

ALIGN=2 это видимо и есть 4, т.е. выравнивание 2 в степени (ALIGN)

Нет, ALIGN задается в байтах, но должен быть степенью 2.

[Alexey Bishletov]

ALIGN=2 это видимо и есть 4, т.е. выравнивание 2 в степени (ALIGN)

Нет, ALIGN задается в байтах, но должен быть степенью 2.

Я забыл, что речь идет про Keil, т.е. мог и соврать (нет у меня его). Но IAR и gcc 3.ххх воспринимают ALIGN как степень для двойки.

[zltigo]

Но IAR и gcc 3.ххх воспринимают ALIGN как степень для двойки.

Никогда никому больше этого не говорите :-).
ALIGN должен быть результатом возведения двойки в степень.

[Alexey Bishletov]

Но IAR и gcc 3.ххх воспринимают ALIGN как степень для двойки.

Никогда никому больше этого не говорите :-).
ALIGN должен быть результатом возведения двойки в степень.

Чем он должен быть я не знаю, но как факт:
Для IAR читаю в документации (EWARM_AssemblerReference.pdf)

Код

ALIGN align [,value]
...
align Exponent of the value to which the address should be aligned, in the range 0
to 30. For example, align 1 results in word alignment 2

Для gcc провожу эксперимент (в документации как-то это туманно отражено или я не то читал)

Код

  .section .text2, "ax"
  .code 32
  .align 2
lbl1:
  mov r0, #0x01

section .text2
00000000 <lbl1>:
00000000 E3A00001 mov r0, #0x1

Код

  .section .text2, "ax"
  .code 32
  .align 4
lbl1:
  mov r0, #0x01

section .text2
00000000 <lbl1>:
00000000 E3A00001 mov r0, #0x1
00000004 E1A00000 nop
00000008 E1A00000 nop
0000000C E1A00000 nop

Так как же у Keil-а?

[Alex03]

Для gcc провожу эксперимент (в документации как-то это туманно отражено или я не то читал)

.align abs-expr, abs-expr, abs-expr

Pad the location counter (in the current subsection) to a particular storage boundary. The first expression (which must be absolute) is the alignment required, as described below.

The second expression (also absolute) gives the fill value to be stored in the padding bytes. It (and the comma) may be omitted. If it is omitted, the padding bytes are normally zero. However, on some systems, if the section is marked as containing code and the fill value is omitted, the space is filled with no-op instructions.

The third expression is also absolute, and is also optional. If it is present, it is the maximum number of bytes that should be skipped by this alignment directive. If doing the alignment would require skipping more bytes than the specified maximum, then the alignment is not done at all. You can omit the fill value (the second argument) entirely by simply using two commas after the required alignment; this can be useful if you want the alignment to be filled with no-op instructions when appropriate.

The way the required alignment is specified varies from system to system. For the a29k, arc, hppa, i386 using ELF, i860, iq2000, m68k, m88k, or32, s390, sparc, tic4x, tic80 and xtensa, the first expression is the alignment request in bytes. For example .align 8 advances the location counter until it is a multiple of 8. If the location counter is already a multiple of 8, no change is needed. For the tic54x, the first expression is the alignment request in words.

For other systems, including the i386 using a.out format, and the arm and strongarm, it is the number of low-order zero bits the location counter must have after advancement. For example .align 3 advances the location counter until it a multiple of 8. If the location counter is already a multiple of 8, no change is needed.

This inconsistency is due to the different behaviors of the various native assemblers for these systems which GAS must emulate. GAS also provides .balign and .p2align directives, described later, which have a consistent behavior across all architectures (but are specific to GAS).