Hello George,
GS>>> Который "плохо ложится" в концепции структурного программирования GS>>> и очень плохо реализуется "сишными" командами. AM>> Может приведешь пример, из своей практики?
GS> Тут уже мелькал один образчик. С несколькими точками входа. Добавить ещё GS> "специфические" команды конкретного процессора, наличие которых может сделать GS> реализацию какой-то задачи заметно более просто - станут понятны другие GS> резервы для оптимизации.
Их не так много, как ты хочешь думать. В любом случае, они не ужмут код на порядок. Если до 2-ух раз и удастся дотянуть, да и то далеко не всегда.
GS>>> Ты исходнички АОH'овские погляди, поймёшь, что прерывания здесь GS>>> не помогут. AM>> Я еще раз говорю, мы не АОH обсуждаем, а общие подходы.
GS> Я привожу конкретный пример, иллюстрирующий возможные проблемы. Если тебя GS> не убеждает конкретный пример, какой смысл спорить об "общих подходах"?
А я и не спорю, я высказываю свою точку зрения, подкрепляя ее доказательствами в виде исходных текстов. На что мне заявляют, что на асм-е будет на порядок эффективнее, и приводят в пример АОН, но почему то не приводят альтернативный вариант кода на ассемблере, позволяющего "сделать" код после Си на порядок. Приводят код в 1.5 раза эффективнее, тем самым подтверждая мою точку зрения. Просишь показать порядок - приводят в пример АОН.
AM>> Вот и экономили байты, чтобы влезть.
GS> Так развивается _любой_ проект, который приходится длительное время GS> сопровождать. Изначально закладывают некоторый запас, но "втискиваться" GS> в него позже бывает довольно трудно...
Главное, что те функции, которые заложы в АОН, типа автодозвона по нескольким номерам сразу и прочей подобной лабуды особо никому и не нужны. Было смысл мучаться.
AM>> Сейчас этот же АОH на какой-нибудь AVR или PIC18 ляжет AM>> на Си и не подавится.
GS> Сейчас. Hо сделали устройства, продали их и получили прибыль - тогда. GS> Работу нужно делать вовремя, а не ждать десяток-другой лет, когда появятся GS> "более удобные девайсины".
Я обсуждаю подходы на момент "сейчас". 30 лет назад были другие подходы, и они имели право существовать, потому что были оптимальны на тот период. Во время аоностроителей был такой подход, сейчас он был бы другой. Писание на асм аонов - дело привычки, потому что я думаю, пишут их все те же люди, которые просто не умеют по другому.
GS>>> А я надеялся, что ты не будешь тупо игнорировать мои аргументы и GS>>> конкретные примеры... AM>> Я не видел конкретных примеров кода,
GS> Тебе уже без меня дали пример кода, на который ты сразу начал жаловаться ;)
Цитируй здесь и сейчас, где я жаловался и на что.
AM>> что может быть конкртенее их?
GS> Конкретнее может быть, к примеру, реплика на твоё предыдущее сообщение. GS> В которой ты загнал переменные в xdata. Программист, хорошо знающий систему GS> команд процессора i51, не стал бы таким приёмом резко снижать эффективность GS> работы устройства, принял бы меры по их переносу в область "нормальных" данных. GS> А "сишник" даже и не увидит разницы...
Чушь, все определяется задачей. Вы же сразу взбрыкнули и сказали, что это неправильно, потому что сам дурак, не туда положил. Впрочем и от тебя с удовольствием выслушаю совет по приему пакета в 250 байт в iram.
GS>>> пользоваться ассемблером и не владеет "чисто ассемблерными" GS>>> приёмами оптимизации. AM>> Всем владеет одинаково.
GS> Это больша-ая редкость!
ты забыл добавить - имхо.
AM>> Сначала писал на асм несколько лет,
GS> Я тоже писал на асме несколько лет. И ещё несколько лет. И только после этого GS> начал овладевать действительно грамотными приёмами программирования на асме...
Еще только начал? И ты советуешь свой путь другим - "вы ребята потерпите, к сорока годам у вас точно начнет получаться".?
AM>> потом перешел на Си, таких здесь много.
GS> Много, кто спорит. Hо численность - не аргумент правильности. Один профи GS> может написать такой код, который вся эха откажется считать реализуемым ;-)
И этот профи, конечно ты?
GS> Умение зависит от человека. Возможности - от инструмента. Ассемблер - более GS> "острый" инструмент. Который не всякому программисту даётся...
Да ничего в асме нет сложного. Свободы больше- да, сложности нет, больше рутины. Более острый - да, но не позволяющий достигать изначально заявленных порядков по коду и какой-то экономии ОЗУ.
AM>> времени впрочем тоже.
GS> Время уходит отнюдь не только на набивку исходника!
Да, обычно в перерывах пытаются думать.
AM>>>> Я как раз рассматриваю общий подход. GS>>> А это не даст тебе возможность понять, откуда вдруг берётся такой GS>>> выигрыш на конкретных задачах ;) AM>> Я вижу этот выигрыш. И вижу проигрыш. Я жертвую выигрышем, даваемым AM>> эффективностью асма, взамен получаю сокращение времени на разработку и AM>> простоту сопровождения.
GS> Верю. А у меня строго обратная картина. Привычки, навыки, особенности GS> конкретных задач. Каждый решает для себя как и на чём программировать. GS> И не нужны нам здесь "религиозные войны"! ;)
А я тебя и не убеждаю. Я лишь утверждаю, что оверхед Си не такой большой, каким ты хочешь его прадстваить. Не порядок, и даже не 2 раза в подавляющем большинстве случаев.
AM>> Си позволяет решать задачу хоть снизу-вверх, хоть сверху-вниз. AM>> Чаще я начинаю с написания HAL, потом двигаюсь вверх.
GS> Снова приведу маленький пример. Звук в АОH'ах на Z80 формировался следующим GS> образом: один канал 53-го таймера переводился в режим генерации импульса, GS> длительность этого импульса соответствовала текущему уровню сигнала. GS> Частота запуска этого канала таймера определялась программной задержкой - все GS> ветви алгоритма должны были крутиться в цикле чётко заданного периода ШИМ GS> (с точностью до машинного такта!) GS> Расскажи, как такое можно спроектировать на сях...
Никак. Я нигде не утверждал, что Си - панацея. Но для современного положения дел - берется uC с аппаратнрым ШИМ и все пишется на Си, без особых хлопот по подсчету тактов.
GS>>> Как раз в соседних письмах тебе Максим Полянский нашёл время GS>>> продемонстрировать, как 4 сишных локальных переменных превратить в GS>>> ноль ассемблерных. AM>> Там переменные упали в регистры,
GS> Hу да, "по щучьему велению"! ;) Их _программист_ распределил по регистрам.
Какой программист? Компилятор Си счел возможным разместить их в регистрах. Что и было прямо сказано в листинге.
GS> Зная, что нужно обрабатывать эффективно, а что может и в памяти полежать.
Я говорю про код после Си - там все в регистрах.
AM>> память не зарезервировалась, значит их нет.
GS> А сишникам в этой ситуации остаётся только уповать на "интеллект" конкретного GS> компилятора. Зато думать меньше надо ;)
Меньше заботиться о частностях. Эффективность- не самоцель.
AM>> А если бы был процессор с аккумулятором и регистров
GS> "Если бы у бабушки..." (c)
GS> Интересная у тебя реакция на _конкретные_ примеры, сразу тему начинаешь GS> менять.
Приведенный пример подтвердил мою правоту, оверхед примерно в тех рамках, что и был заявлен. Какой смысл мне менять тему?
GS> Учись отличать условия задачи и конкретную реализацию алгоритма её решения.
AM>> Алгоритмы, реализуемые на асм и Си должны быть одинаково AM>> оптимальными, или одинаково убогими.
GS> С какой это радости?
С той, что это корректный подход для определения эффективности компилятора.
GS> А если программист на асме увидит более эффективный GS> путь решения задачи,
Я не пытаюсь сравнивать гениальность программистов. Я говорю, что если _этот_ программист будет писать на асм, реализуя алгоритм X, и получит N килобайт кода, и потом _этот же_ программист будет писать на Си все тот же алгоритм X, то он получит примерно 1.3*N килобайт кода.
GS> он должен прикинуться идиотом?
Нет, если будет найден более эффективнй алгоритм, то он будет реализован как на Си, так и на асм, поскольку программист один и тот же.
AM>> В этом смысл сравнения компилятора Си и асм.
GS> Hет никакого смысла сравнивать эффективность реализации, если одному GS> из соперников по "идейным соображениям" "связать руки"!
Нет соперников, есть один и тот же программист, перед ним стоит выбор Си vs Asm.
AM>> В противном случае это будет соревнование GS и AM в создании AM>> оптимальных алгоритмов.
GS> А для тебя что, новость, что программы пишут именно программисты? GS> Пусть и пользуясь какими-то подходящими для себя программами...
А для тебя новость, что конкретное устройство реализует конкретный программист, и перед ним стоит выбор Си vs Asm? И что он ни с кем не состязается, просто выбирает инструмент, зная, что он выигрывает, а что проигрывает.
AM>> Вот и запусти.
GS> Так напиши для начала, тогда каждый запустить сможет ;) Конкретную GS> (хорошо формализованную и решаемую за разумное время) задачу я уже GS> называл - машинонезависимая форт-система. Hа ассемблере это вгоняется GS> в 2-4 килобайта, в зависимости от требуемого соотношения эффективность/ GS> объём кода.
Мне не интересно состязание программистов. Этот спор о другом. О дурилке, что асм на порядок эффективнее Си на одинаковых алгоритмах.
AM>> Я бы хотел посмотреть форт, но не могу из-за недостатка времени. AM>> Я тебе могу встречное предложение сделать. Давай напишем стек AM>> SLIP/IP/TCP. Hо ты ведь точно также скажешь, что у тебя не времени AM>> изучать стек протоколов.
GS> Пример ведь не я просил, так что выбор за мной ;)
То есть ты точно также слил, при виде незнакомой задачи.