Форум РадиоКот

pirotehnick писал(а):Вероятно с тем, что компилятор не может преобразовать операцию умножения 16 разрядного значения на 8 - разрядное, т.к. инструкции умножения поддерживают лишь умножение двух 8-разрядных чисел с 16-разрядным результатом.

smac писал(а):

pirotehnick писал(а):Вероятно с тем, что компилятор не может преобразовать операцию умножения 16 разрядного значения на 8 - разрядное, т.к. инструкции умножения поддерживают лишь умножение двух 8-разрядных чисел с 16-разрядным результатом.

Сильно сомневаюсь, инструкции сложения регистров вообще работают с 8-ми битными операндами, однако с помощью МК можно сложить числа практически любой (ограничено оперативной памятью МК) разрядности, т. е. флаг переноса еще никто не отменял.

smac писал(а):с помощью МК можно сложить числа практически любой (ограничено оперативной памятью МК) разрядности

ARV писал(а):я уже говорил - pirotehnick фантазирует.

ARV писал(а):в Си все значения сначала приводятся к типу int

ARV писал(а):все переменные имеют тип unsigned char. значит, сначала PORTD и PORTB будут приведены к типу int

pirotehnick писал(а):Он приводит их к типу int, но только внутри самой программы компилятора. Т.е. если мне допустим нужно сложить PORTD+PORTB и вывести результат в PORTC, то ни к какому 32 разрядному значению он их приводить не должен, а просто сложить два 8-разрядных значения и вывести результат в PORTC, забив, при этом, на переполнение.
Т.е. он должен сгенерить что-то вроде этого:
//...................
add r16, r17
out PORTC r16
//...................

По-хорошему компилятор сам должен определять разрядность значений и генерить соответствующий код.

ARV писал(а):это вы так считаете. а компилятор обязан следовать требованиям стандарта Си.

ARV писал(а):если он будет делать так, как говорите вы - это будет плохой компилятор.

ARV писал(а):int для AVR: вовсе не 32, а всего 16 бит.

ARV писал(а):я вам уже сказал: есть стандарт Си, и компилятор должен ему следовать. только в этом случае гарантируется, что исходник будет одинаково компилироваться разными компиляторами. если ваш компилятор делает не по стандарту - это нестандартный компилятор, что можно понимамть как синоним "плохой".

Neekeetos писал(а):Вообще говоря компилятор для исходника указанного в самом начале должен сам вычислить произведение двух констант и подставить при компиляции число, то что он этого не делает а пытается интерпретировать операции( и видимо впихнуть это несчастное умножение в код программы) , является самым настоящим багом, а раз так то и предложить можно только считать это произведение за него до тех пор пока не исправят разработчики винавр.

ARV писал(а):

Neekeetos писал(а):Вообще говоря компилятор для исходника указанного в самом начале должен сам вычислить произведение двух констант и подставить при компиляции число, то что он этого не делает а пытается интерпретировать операции( и видимо впихнуть это несчастное умножение в код программы) , является самым настоящим багом, а раз так то и предложить можно только считать это произведение за него до тех пор пока не исправят разработчики винавр.

бред какой-то говорите... компилятор предупреждает, что результат выражения выходит за пределы int. этот результат получается на этапе компиляции - где тут баг?! все верно.

long i;

int main(void)
{   
   i=4690*32; //Тут возникает ошибка, i=150080
	return i;
}

	.file	"test-test.c"
	.arch avr2
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__tmp_reg__ = 0
__zero_reg__ = 1
	.global __do_copy_data
	.global __do_clear_bss
	.text
.global	main
	.type	main, @function
main:
/* prologue: frame size=0 */
	push r28
	push r29
	in r28,__SP_L__
	in r29,__SP_H__
/* prologue end (size=4) */
	ldi r24,lo8(19008)
	ldi r25,hi8(19008)
	ldi r26,hlo8(19008)
	ldi r27,hhi8(19008)
	sts i,r24
	sts (i)+1,r25
	sts (i)+2,r26
	sts (i)+3,r27
	lds r24,i
	lds r25,(i)+1
	lds r26,(i)+2
	lds r27,(i)+3
/* epilogue: frame size=0 */
	pop r29
	pop r28
	ret
/* epilogue end (size=3) */
/* function main size 27 (20) */
	.size	main, .-main
	.comm i,4,1
/* File "test-test.c": code   27 = 0x001b (  20), prologues   4, epilogues   3 */

ARV писал(а):не знаю, откуда у вас такие результаты... вот листинг,

ARV писал(а): 7a: 08 95 ret[/code]как видите, никакого дубля младшего слова в старшем нет.

ARV писал(а): возможно, часть выражений вычисляется при обработке препроцессором - тут я точно не скажу, надо смотреть документацию. однако, для числовой константы по умолчанию используется тип int (который используется по умолчанию и для любой переменной) - это факт.
да, компилятор AVR-GCC 4.3.0 (WinAVR 20080610)

Neekeetos писал(а):Посмотрел стандарт, обсуждаемый случай называется constant-folding, это оптимизация позволяющая упростить константные выражения на этапе компиляции. Судя по описанию это упрощение делается с использованием базовых типов в тч для целочисленных констант будет использоваться int если у нету явного приведения. Для авр int это 16 бит значение так что похоже компилятор сделал все верно отбросив старшие два байта у результата вычислений тк использовалась 16 бит арифметика.