WINAVR

Hello, George Shepelev! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Fri, 07 Oct 2005 15:37:21

DT>>>>> type Temperature is delta 0.01 range -100..100; DO>>>> А во что скомпилируется работа с таким типом? DT>>> В целое масштабированное (fixed point) и в целочисленную DT>>> арифметику. DO>> Ага, и еще в рантайм проверки выхода за диапазон с достаточно DO>> громоздким (поскольку стандартным и универсальным) DO>> обработчиком исключений...

GS> Фокус в том, что если упростится написание софта, могут ведь GS> и в "железо" встроить необходимые проверки...

Вот прямо все производители разогнались в железо громоздкие проверки пихать... Тем более, что для проверки диапазона нужно как минимум его границы где-то хранить, причем для каждой переменной. Это раз. Два, допустим вышла переменная за свои границы, что делать? В случае класса - что в его методах написано, а в случае встроенной в язык, что делать?

dima

Hello, Igor Ulanov! You wrote in conference fido7.ru.embedded to Vladimir Vassilevsky on Sat, 08 Oct

IU> Что в остатке? Hедостатки Си: IU> 1. 3-ной проигрыш по объему и по скорости.

Реально на смешанном коде (типа городской езды) процентов 20-30 проигрыша при многократном выигрыше в скорости разработки и сопровождаемости.

dima

Т.е. те, кто читает Си без проблем - либо их меньшенство, либо они ненормальные? :-)))))

Китайцев не так уж и мало, и они тоже выражают мысли на естественном языке

- с помощью иероглифов:-)))))) А если серьезно, то все люди _изначально_ выражают мысли на _естественном_ языке (русском, английском - кто какой знает), а потом записывают его на машинном... Если вам удобнее читать BCND, BACC, SPLK, LACC, BLDD и т.п., а не if, else, do while, break, continue и т.п. (которые взяты из _ествественного_ языка) то может вам удобнее и мысли будет выражать например на китайском _естественном_ языке :)))))

Первый раз слышу как про сполшные трюки в Си, так и про стиль "write only". "write only" - поясните, первый раз сталкиваюсь. Комментирование программ зависит от воспитания программиста, а не от языка...

Про комментарии никто и не спорит...

Так и не понял в чем заключается трюкачество в Си и как он его провоцирует. Можете пример привести, конкретный? Очень жду. Если человеку в принципе чужда дисциплина, то он на любом языке будет "халявить"... даже на естественном...

Комментарии должны быть достаточны для понимания алгоритма. Тоже самое могу сказать и про асм - "во много раз бОльшим объёмом комментария". Мы вроде говорили про нормальных, грамотных разработчиках, а не про "кульхацкеров"...

А описка в асме не даст труднообнаружимую ошибку? Например: написал LRET - Long return вместо IRET - Interrupt return Мелкая это ошибка? Клавиши I и L находятся рядом по диагонали - можно и промазать если "зевать". а в некоторых шрифтах I - в верхнем регистре , не отличишь от l в нижнем, а ассемблеры то плюют на регистр мнемоник... Пишите правильно - и будет вам счастье на любом языке:) Я могу высказать такие же жалобы на наглядность асм-а, но не буду - поскольку все зависит от стиля оформления программы и знания языка на котором она пишется.

Так что все ваши доводы оказываются весьма субъективными. Надеюсь для писания на PC баз данных с кучей клиентских мест вы не будете настаивать на применении асм-а вместо С++, VB и SQL-я :))))

Hello, Alex Mogilnikov! You wrote in conference fido7.ru.embedded to Vladimir Vassilevsky on Sun, 09 Oct

VV>> Hапример, нужно умножить u8 на s16 и получить 24-битный результат. VV>> Си сначала будет промоутить оба сомножителя до 32 бит, потом VV>> вызовет долгое и нудное умножение 32x32.

AM> Hичто не мешает компилятору сгенерить код, выполняющий AM> умножение 8x16=24.

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

AM> компиляторы этого не делают, или делают недостаточно AM> оптимально, это проблемы компиляторов, а не правил языка.

Это, увы, проблема того, кто использует компилятор.

dima

Hello, Igor Ulanov! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Sun, 09 Oct 2005 14:31:12

DO>> Реально на смешанном коде (типа городской езды) процентов DO>> 20-30 проигрыша при многократном выигрыше в скорости DO>> разработки и сопровождаемости.

IU> Здесь абсолютная величина в принципе не очень важна, пусть IU> даже 3-х кратный проигрыш. Все равно трудно оценить удобство

Это много... Оценить удобство в принципе можно, как и затраты от трехкратного роста кода. Когда же в реальности он меньше двукратного, это уже оценить в общем случае действительно трудно. Потому как скорость кода и его размер, пока влазят, стоят одинаково при любых значениях.

IU> разработки и сопровождения Си над ассемблером в абсолютных IU> величинах. А в три раза все-таки звучит более конкретно и IU> менее страшно, чем просто "в разы":) IU> В целом уже поднадоел спор и хотелось бы выявить хоть IU> какие-то результаты его.

Да не может у него быть никаких результатов. Ты споришь с человеком, с которым бессмысленно спорить - он просто не разбирается в предмете спора.

dima