Можно ли заработать на знании ассемблера, причем довольно не плохом знании,
хотя сам программистом профессионально никогда не работал, но последнее время хочется заняться именно этим.
хотя сам программистом профессионально никогда не работал, но последнее время хочется заняться именно этим.
а откуда тогда ассемблер знаете, если программистом не работали?
Metal kыnG
veteran
Ассемблер это больше философия и знание платформы в железе. Хотя сейчас ассемблер нужен только для работы с хитрыми устройствами (при написании систем реального времени) или для микроконтроллеров но там без знания схемотехники делать вообще нечего. А так ассемблер для среднего программиста это не более чем один из этапов обучения.
Боюсь, в Новосибирске ассемблер мало кому нужен. Тут все еще поп-технологии от программирования в цене, а понимать что под ними ни к чему.
Впрочем, ассемблер сам по себе, как уже сказали здесь, требуется как таковой нечасто, при решении специфических задач. Но знать его никогда не помешает.
Впрочем, ассемблер сам по себе, как уже сказали здесь, требуется как таковой нечасто, при решении специфических задач. Но знать его никогда не помешает.
Сможете создавать приложения (нужные для бизнеса) эффективнее и дешевле, чем на том же Си, Делфи и т.п. - будете востребованный. А так - только где нужен узкий специалист.
Сейчас читают
Сибирские Сети, отзывы по качеству
235646
990
Любители переднеприводных карбюраторных ВАЗ'ов -4 (часть 2)
197437
968
Чистая слобода 2 - дома Титова, 19,20,21,26,27,28,29,30 стр (часть 2)
210914
1000
создавать приложения на ассемблере - это все равно что детским совочком рыть котлован под строительство бизнес-центра.
Developer
guru
Даже для написания систем реального времени сейчас больше С используется. Вакансий с требованием к ассемблеру вообще не видел.
Да ну? "А Ви пгобовали?"
При грамотном подходе и наработанных базовых библиотеках, скорость писания никак не отличается. Причем это, заметьте, не моё утверждение, а результаты серьезных научных изысканий. Сцылка: книжка "Начала науки о программах", автора - не помню.
От себя замечу только, что при наработанных библиотеках можно писать полностью законченное приложение, которому собственно и ОС - не нужна. Воткнул ДВД, включил комп и всё. Сиди и работай.
При грамотном подходе и наработанных базовых библиотеках, скорость писания никак не отличается. Причем это, заметьте, не моё утверждение, а результаты серьезных научных изысканий. Сцылка: книжка "Начала науки о программах", автора - не помню. От себя замечу только, что при наработанных библиотеках можно писать полностью законченное приложение, которому собственно и ОС - не нужна. Воткнул ДВД, включил комп и всё. Сиди и работай.
А сам по себе - любой бесполезен ))) А вот вкупе со знаниями электроники-схемотехники, знание ассемблера пары-другой МК будет плюсом.
А знание x86-го ассемблера плюсом не будет, так, малозначительный факт. Ну, как мне кажется.
А знание x86-го ассемблера плюсом не будет, так, малозначительный факт. Ну, как мне кажется.
ну так для этого нада сначала "наработать библиотеки"
нашел книгу в поисковике...
год издания 1981.
да, серьезный источник фактов о технологиях программирования в 2009-м году.
год издания 1981.
да, серьезный источник фактов о технологиях программирования в 2009-м году.
ННП
Помню как учил это безобразие......как экзамены сдавал зам.кафедры.........что то мне подсказывает что было это бесполезным занятием))
Помню как учил это безобразие......как экзамены сдавал зам.кафедры.........что то мне подсказывает что было это бесполезным занятием))
Алексей11111
experienced
Ассемблер это для горцев и прочих бессмертных :-) Да,и ещё для очень оптимистичных людей!
ННП
вообще, как показывает наш опыт, даже для контроллеров применение ассемблера весьма ограничено сейчас. частоты растут, от ассемблера отказываются в сторону Си для упрощения процесса разработки. Какие-то критичные ко времени выполнения участки обязательно будут писаться на асме, да. Для сигнальников пишут опять же на Си, кроме, опять же, критичных мест. Однако, у мощных современных сигнальников архитектура и ассемблер такой, что проще застрелиться, чем в нем разобраться.
вообще, как показывает наш опыт, даже для контроллеров применение ассемблера весьма ограничено сейчас. частоты растут, от ассемблера отказываются в сторону Си для упрощения процесса разработки. Какие-то критичные ко времени выполнения участки обязательно будут писаться на асме, да. Для сигнальников пишут опять же на Си, кроме, опять же, критичных мест. Однако, у мощных современных сигнальников архитектура и ассемблер такой, что проще застрелиться, чем в нем разобраться.
Craxx'у: Ну а как же-с...
Andron'у: а что, что-то сильно поменялось в восприятиях человека? Или теперь проги пишутся без нажимания клавиш и толкания мышек, прямо из головы "заказчика"...
Год издания книги никак не умаляет её достоинств. Книги Кнута, Пратта, Дейкстры, Баррона, Касьянова, Ершова и многих других... изданы гораздо раньше, но их значение может даже и выше чем было в то время...
Andron'у: а что, что-то сильно поменялось в восприятиях человека? Или теперь проги пишутся без нажимания клавиш и толкания мышек, прямо из головы "заказчика"...
Год издания книги никак не умаляет её достоинств. Книги Кнута, Пратта, Дейкстры, Баррона, Касьянова, Ершова и многих других... изданы гораздо раньше, но их значение может даже и выше чем было в то время...
asm, нужен сильно людям работающим в отрасли информационной безопасности. Движки некоторых AV написаны на асме, про вирусы я вообще молчу.
в восприятии - нет, а в методах разработки - да.
как бе, одним мировосприятием программы не пишутся.
как бе, одним мировосприятием программы не пишутся.
нашел книгу в поисковике...Недавно скачивал книжки по асму за 2004 - 2005 год. Вы, видимо, искали самый древний учебник - его и нашли.
год издания 1981.
да, серьезный источник фактов о технологиях программирования в 2009-м году.
Кстати, был случай, когда спец по c/c++ с высшим математическим образованием занялся проблемой передачи информации через последовательный порт. Он был крайне изумлен, что единый и неделимый тип Интежер состоит из байтов, которые надо собирать на той стороне порта в последовательности, зависящей от аппаратной части. Или другой случай - надо было выжать из процедуры обработки изображения максимум производительности. После всех ухищрений применили крайнюю меру - переписали критические участки на ассемблере. Производительность выросла в 2 раза.
Короче, владение ассемблером наряду с другими языками - арсенал профессионального программиста.
Да ну? И в чём разница - пояснить сможете, или как?
Остальным: ИМХО конечно, но современному прогеру-пхпшнику знать ассемблер, впрочем как и читать классиков - совершенно не обязательно. Достаточно знать абревиатуры MVC и др...
Остальным: ИМХО конечно, но современному прогеру-пхпшнику знать ассемблер, впрочем как и читать классиков - совершенно не обязательно. Достаточно знать абревиатуры MVC и др...
особого смысла оспаривать глупости не вижу, но так, в качестве наводящего вопроса...
сколько уйдет человеко-часов времени для разработки хотя бы стека TCP-IP на ассемблере, чтобы запускаться с пресловутой болванки без ОС? а чтобы этот стек работал с сетевых картах на различных микросхемах?
сколько уйдет человеко-часов времени для разработки хотя бы стека TCP-IP на ассемблере, чтобы запускаться с пресловутой болванки без ОС? а чтобы этот стек работал с сетевых картах на различных микросхемах?
А Ви пгобовали?"
При грамотном подходе и наработанных базовых библиотеках, скорость писания никак не отличается.
а вы получается пробовали? я бы посмотрел, сколько времени заняло бы написание на ассемблере простейшего приложения под sql, с выведением результатов запросов пользователю. имхо тут даже "наработанные базовые библиотеки" не помогут.
Не только "пгобовал", но и сдавал Заказчику в лице военпреда... давно правда...
"пробовал" - в смысле, сравнивал скорость разработки
особого смысла оспаривать глупости не вижу, но так, в качестве наводящего вопроса...Пример из практики. Работала группа "железячников" над созданием платы управления неважно чего. На плате красовался x86 процессор со своим окружением. Для интеллектуального усиления им в группу был добавлен крутой cи-программер, который быстро написал нужный код. Но код не помещался в микросхему, предназначенную для прошивки. Переделывать плату было дорого и долго. Один из "железячников" написал тоже самое на ассемблере, его код и зашили в микросхему. А чистого сишника с позором прогнали.
сколько уйдет человеко-часов времени для разработки хотя бы стека TCP-IP на ассемблере, чтобы запускаться с пресловутой болванки без ОС? а чтобы этот стек работал с сетевых картах на различных микросхемах?
Че та я сомневаюсь, что с С на ассемблер переписывание ускорит прям в два раза программу, видать очень неоптимально было написано. Ну и спец по С, который не знает, из чего состоят типы данных, это явно не спец. Видать взяли какого недотепу сишнего вы, и сравниваете непотимальный сишный код с ассемблерным.
а вы получается пробовали?Вы правы, писать SQL-запросы на асме не имеет смысла, также, как и забивать гвозди микроскопом. Но из этого не следует, что микроскоп - некудышний инструмент. Возвращаясь к SQL, замечу, что для профессионального проектирования БД и запросов необходимо знать и особенности построения индексов, и особенности записи страниц БД на носителе, и пр. тонкости. Своего рода "ассемблер", находящийся под поверхностным SQL/
я бы посмотрел, сколько времени заняло бы написание на ассемблере простейшего приложения под sql, с выведением результатов запросов пользователю. имхо тут даже "наработанные базовые библиотеки" не помогут.
дык я не спорю о незаменимости ассемблера в ряде задач...
у Вас пример очень показательный - иллюстрирует ситуацию, когда ассемблер действительно нужен.
Вопрос в том, сколько уходит времени на разработку сложных систем на языке высокого уровня и сколько на ассемблере.
Из своего опыта могу рассказать... Голова... но он Си не знает, для контроллера пишет на асме. Причем, имеет привычку экономить процессорное время, не всегда значительно)))
В-общем - разбираться в его программах - полный атас! Комментированный код, с алгоритмами, но пока въедешь... Получается, что работает чуточку быстрее, но работать с его кодом чужому программисту - очень тяжело. Ну и пишет он не спеша, с душой)))
Сам я сейчас для сигнальника решил использовать не Си... а С++.
На скорости работы не сказывается - практически все конструкции решаются на этапе компиляции, а защита от ошибок более серьезная. Плюс структура программы получается понятней.
Но есть функции, которые я пишу на ассемблере - Сишный код даже с использованием специальных конструкций, заточенных под процессор, значительно проигрывает в скорости.
у Вас пример очень показательный - иллюстрирует ситуацию, когда ассемблер действительно нужен.
Вопрос в том, сколько уходит времени на разработку сложных систем на языке высокого уровня и сколько на ассемблере.
Из своего опыта могу рассказать... Голова... но он Си не знает, для контроллера пишет на асме. Причем, имеет привычку экономить процессорное время, не всегда значительно)))
В-общем - разбираться в его программах - полный атас! Комментированный код, с алгоритмами, но пока въедешь... Получается, что работает чуточку быстрее, но работать с его кодом чужому программисту - очень тяжело. Ну и пишет он не спеша, с душой)))
Сам я сейчас для сигнальника решил использовать не Си... а С++.
На скорости работы не сказывается - практически все конструкции решаются на этапе компиляции, а защита от ошибок более серьезная. Плюс структура программы получается понятней.
Но есть функции, которые я пишу на ассемблере - Сишный код даже с использованием специальных конструкций, заточенных под процессор, значительно проигрывает в скорости.
Бог мой! Да в чём вопрос-то? Сравнение скоростей разработки и методики такого сравнения приведены в указанной книжке. Год староват, но выводы верны и по сей день, а именно: полная скорость разработки конечного приложения на Ассемблере - никак не больше чем на ЯВУ! Как ни странно. Думаю"на сегодня" можно найти аналогичные "более современные" исследования с тем же результатом...
Я же не "просто так" просил уже кого-то назвать "разницу"... а в ответ - тишина. Потому как (опять же при наличии нужных библиотек) особой разницы и нет:
практически на любом Ассемблере есть процедурное программирование, макросы, передача параметров, мненомические имена и все остальные "чудеса" ЯВУ. ООП и прочая "лабуда" не так сложно решается нужным набором библиотек... так любимые некоторыми абревиатуры MVC и прочие - это всего лишь технологии и применимы к программированию в т.ч. и на Ассемблере. Только ко всему этому "в плюс" - скорость, компактность и качество реализации. Если конечно головой думать и руки "на месте". Но это полезно на любом языке.
Тому кого так пугает SQL: вот как-то нисколько не сомневаюсь (хотя ни разу и не видел) что большая часть SQL "энджайнов" написана или на Ассемблере или на С, что по большому счету, "одно и то же". Ну разбирают они как-то этот самый SQL и ни чё, вроде как все даже пользуются. Исходники mySql так ваще вроде как пока еще доступны... особо любопытным можно качнуть и посмотреть долю кода на Ассемблере, С и остальных ".оп"ах
Нормальному спецу, абсолютно все равно на чем делать релиз. Хоть на языке Мумбу-Юмбу. Язык - всего лишь набор правил. Просто большинство здесь даже не представляет что такое Ассемблер... тока слышали...
Я же не "просто так" просил уже кого-то назвать "разницу"... а в ответ - тишина. Потому как (опять же при наличии нужных библиотек) особой разницы и нет:
практически на любом Ассемблере есть процедурное программирование, макросы, передача параметров, мненомические имена и все остальные "чудеса" ЯВУ. ООП и прочая "лабуда" не так сложно решается нужным набором библиотек... так любимые некоторыми абревиатуры MVC и прочие - это всего лишь технологии и применимы к программированию в т.ч. и на Ассемблере. Только ко всему этому "в плюс" - скорость, компактность и качество реализации. Если конечно головой думать и руки "на месте". Но это полезно на любом языке.
Тому кого так пугает SQL: вот как-то нисколько не сомневаюсь (хотя ни разу и не видел) что большая часть SQL "энджайнов" написана или на Ассемблере или на С, что по большому счету, "одно и то же". Ну разбирают они как-то этот самый SQL и ни чё, вроде как все даже пользуются. Исходники mySql так ваще вроде как пока еще доступны... особо любопытным можно качнуть и посмотреть долю кода на Ассемблере, С и остальных ".оп"ах
Нормальному спецу, абсолютно все равно на чем делать релиз. Хоть на языке Мумбу-Юмбу. Язык - всего лишь набор правил. Просто большинство здесь даже не представляет что такое Ассемблер... тока слышали...
Год староват, но выводы верны и по сей день, а именно: полная скорость разработки конечного приложения на Ассемблере - никак не больше чем на ЯВУ!а эта... ниче, что Java вышла в 1995-м году?
в книге 81-го года об этом факте ничего не писали, нет?
Че та я сомневаюсь, что с С на ассемблер переписывание ускорит прям в два раза программу, видать очень неоптимально было написано. Ну и спец по С, который не знает, из чего состоят типы данных, это явно не спец. Видать взяли какого недотепу сишнего вы, и сравниваете непотимальный сишный код с ассемблерным.Я не находил в книжках по си разжевывание того факта, что тип интежер на разных платформах представляется по-разному. Си-шников учат обратному: интежер - он и в африке интежер. Но если вы подразумеваете под грамотным си-шником знатока си + ассемблер, то я с вами согласен. Помню, для примера написал консольное приложение "Hello, word" на асме и на си. Первое занимало меньше 100 байт (точно не помню), второе - 13 Килобайт! Я был потрясен!
В Новосибирске асм нужен менее чем в 1% разработки, пройдет еще несколько лет, техника будет выпускаться более скоростная - про асм в новосибирске вообще забудут. Останется он нужен для выскотехнологичного производства зарубежом и в Москве , опять таки в менее 1% всей разработки.
Вообще знать ассемблер можно для общего развития, но спецы-железнячнки в ИТ получают гораздо меньше остальных собратьев, поэтому становится спецом по ассемблеру смысла нет.
Кстати такая же печальная история в сфере пром. автоматизации - вроде дело нужное и важное, но зп в этой сфере обычно одни из самых маленьких в ИТ. вот такие печальные дела.
Вообще знать ассемблер можно для общего развития, но спецы-железнячнки в ИТ получают гораздо меньше остальных собратьев, поэтому становится спецом по ассемблеру смысла нет.
Кстати такая же печальная история в сфере пром. автоматизации - вроде дело нужное и важное, но зп в этой сфере обычно одни из самых маленьких в ИТ. вот такие печальные дела.
учат/не_учат, но длину целого указывают в книжках)))
а в книгах, которые учат как нужно проектировать и писать программы, явно указывают, что зависимости от длины стандартных типов платформы нужно избегать...
ну это так... оффтопег)
а в книгах, которые учат как нужно проектировать и писать программы, явно указывают, что зависимости от длины стандартных типов платформы нужно избегать...
ну это так... оффтопег)
ОС - не нужна. Воткнул ДВД, включил комп и всё. Сиди и работай.
У меня вопрос к Tolstopuzу, это будет работать только на том компе, для которого написано приложение, или на любом? А как подключить другой принтер или, например, модем?
У меня вопрос к Tolstopuzу, это будет работать только на том компе, для которого написано приложение, или на любом? А как подключить другой принтер или, например, модем?
Это как обычно зависит от того, что написано в проге. В свое время, были такие игрушки, которые запускались ТОЛЬКО со своей собственной дискеты и никакой ОС не требовали. На экран выводили нормально, любой. Одну такую последний раз юзал году так в 2002 и ничего, нормально запустилась на 3-м пне...
П.С. Ежели писать соблюдая отраслевые стандарты на общение с той или иной периферией, как правило, работает любое устройство одинаково. Мой опыт говорит об этом. А вот ежели изголяться под конкретную железяку, то надо изголяться под все, но код при этом должен писаться соответствующим образом...
По сути, что происходит когда одна железяка работает, а другая нет? Всё крайне просто. Задача, которую выполняет прога для обеспечения её работы "знает" некоторые особенности железяки и их и юзает, а про остальных "знать" не захотела когда еще была в мозгу у программера... решений, как обычно, два: или научить или работать единообразно через стандарт. В момент проектирования было еще и третье: мозги подправить...
Или использование PHP позволяет избежать установки драйверов для жестких дисков, например Raid?
Andron'у: О! Точно. Явы и ПХП не было... и еще пары тысяч других языков и диалектов тожа... и Чо-о? Чего это меняет? Чем программирование (методологически) на "новых" языках отличается от старых?
Можете не отвечать. Во-первых, не сможете, во-вторых все равно флуд.
Автор интересовался Ассемблером. По возможности, я указал на то, что его применимость возможна практически везде и, при дополнительных условиях, нисколько не хуже применимости других языков. В любом случае всегда есть свои преимущества. Опять же ИМХО, его востребованность - практически на нуле. Но мнение о том, что на Асм писать нельзя - просто ошибочно "по незнанию". Можно, еще как можно! Опять же ИМХО: "Все нормальные проги написаны именно на нём!". Остальное - рукотворное г...
П.С. Ежели писать соблюдая отраслевые стандарты на общение с той или иной периферией, как правило, работает любое устройство одинаково. Мой опыт говорит об этом. А вот ежели изголяться под конкретную железяку, то надо изголяться под все, но код при этом должен писаться соответствующим образом...
По сути, что происходит когда одна железяка работает, а другая нет? Всё крайне просто. Задача, которую выполняет прога для обеспечения её работы "знает" некоторые особенности железяки и их и юзает, а про остальных "знать" не захотела когда еще была в мозгу у программера... решений, как обычно, два: или научить или работать единообразно через стандарт. В момент проектирования было еще и третье: мозги подправить...
Или использование PHP позволяет избежать установки драйверов для жестких дисков, например Raid?
Andron'у: О! Точно. Явы и ПХП не было... и еще пары тысяч других языков и диалектов тожа... и Чо-о? Чего это меняет? Чем программирование (методологически) на "новых" языках отличается от старых?
Можете не отвечать. Во-первых, не сможете, во-вторых все равно флуд.
Автор интересовался Ассемблером. По возможности, я указал на то, что его применимость возможна практически везде и, при дополнительных условиях, нисколько не хуже применимости других языков. В любом случае всегда есть свои преимущества. Опять же ИМХО, его востребованность - практически на нуле. Но мнение о том, что на Асм писать нельзя - просто ошибочно "по незнанию". Можно, еще как можно! Опять же ИМХО: "Все нормальные проги написаны именно на нём!". Остальное - рукотворное г...
микроскоп - некудышний инструментТак никто и не утверждал, что ассемблер - бесполезная вещь. Никто и не спорил, что для некоторых задач - это оптимальное решение. Но вот говорить, что скорость разработки на ассемблере и на языках высокого уровня одинакова(автор данного высказывания даже не ограничился С, сказал что на любом языке при "грамотном" подходе) - это все же явная глупость.
Это у Вас компилятор кривой. У меня еще на Турбо С 2.0 выходило одинаково байт в байт. Правда после замены загрузчика и библиотек на свои...
Ваще Ассемблер и С (на С++ сложнее но тоже допустимо) я не различаю, потому как С легко компилируется на Асм даже "руками". Можно писать на С так, что даже не самый умный компилятор будет выдавать код очень близкий к ручному ассемблеру... но для этого надо поработать на Асм... для начала.
Как образец такого кода - исходники Юниксов в сети... есть места, которыми просто восхищаешься, до чего красяво писано...
Ваще Ассемблер и С (на С++ сложнее но тоже допустимо) я не различаю, потому как С легко компилируется на Асм даже "руками". Можно писать на С так, что даже не самый умный компилятор будет выдавать код очень близкий к ручному ассемблеру... но для этого надо поработать на Асм... для начала.
Как образец такого кода - исходники Юниксов в сети... есть места, которыми просто восхищаешься, до чего красяво писано...
Суть той книжки в том, что скорость разработки софта зависит от количества элементарных различений в мозгу прогера (т.е. сложности самой проги) и скорости топтания клавы (и соответственно инструментария - редактора и др...), а не от языка на котором пишется.
Дополнительно доказательство "от противного": если бы это было не так, то с ростом ЯВУ стоимость разработки софта только бы падала, а она растет.
Дополнительно доказательство "от противного": если бы это было не так, то с ростом ЯВУ стоимость разработки софта только бы падала, а она растет.
Metal kыnG
veteran
Даже для написания систем реального времени сейчас больше С используется. Вакансий с требованием к ассемблеру вообще не видел.Да больше используется С/С++ (сам этим по работе занимаюсь) ... ассемблерные кусочки - это либо работа с портами ... либо пересылки/рассылки из которых нужно выжать побольшее производительности.
Опять же с учетом архитектуры современных процессоров затачивать ассемблерный код нужно под конкретный камень или их семейство (для максимальной производительности).
И самый главный недостаток ассемблерного кода - портируемость. Например написали мы мегапупер программу под интелей, зашили в устройство ... все быстро и красиво. И тут появляется более крутая и дешевая железка на АРМ процессорах. Пока программисты писавшие на С/С++ обмывают успешный запуск своего кода на новой железяке, крутой программист на ассемблере переделывает свое творение под другой проц.
По поводу производительности труда... был случай - нужно было быстрое альфа-смешение. Написал на асме - померил ... 14 тактов на точку. 4 часа спустя из 24 строчек кода стало 22 и 7.5 такта на точку + еще ускорение из-за оптимизации по кэшированию ..... конечно самооценка от осознания своей крутости резко поднялась и хлопнула по лбу... но фактически это был спорт не боле того.
Metal kыnG
veteran
ну так для этого нада сначала "наработать библиотеки""если нужна какая-то функция - поищите ее в стандартных библиотеках и библиотеках других разработчиков, если ее там нет, подумайте, а нужна ли она вообще"
Уточню, что бы быть понятым. В си проповедуется независимость от платформы. А о таких фактах, что 32-битное целое, переданное через COM-порт на другое устройство, даже если оно останется 32-битным, может быть изувечено до неузнаваемости - проповедники предпочитают помалкивать. Причина в том, что на другой платформе для этого целого принят иной порядок следования тех же четырех байтов. Лечится внутренней перетасовкой байтов при неизменной длине. Кстати, о длине целого. Умолчать, о том, что си-прога, тщательно оптимизированная и отлаженная на 32-разрядной платформе может рухнуть от переполнения стека на 64-разрядной платформе, или страдать арифметическим переполнением на 16-разрядной - уже не получается - приходится что-то объяснять пастве. Пояснения, чем может оказаться short и long на тех же 16, 32,и 64-разрядных платформах вообще шокируют - надо же так запутать такие простые понятия. Не прошло и нескольких десятилетий - разум начал торжествовать. В си-шарпе появились типы Int16, Int32, Int64. Коротко и ясно, без лишнего словоблудия. Правда, integer неопределенной длины оставили - для любителей покалбасится (смотри выше). Но паства свято верит в межплатформенную независимость - посмотрите, в соседних сообщениях авторы уверены, что на будущей платформе си-прогерам только и останется, что пить шампанское.
А в ассемблере все прямо и честно - и о зависимости от платформы следования байтов в 32-разрядном целом, и не только данные, но и команды известной длины, заодно известно, сколько тактов занимает выполнение команд. Без шаманства и словоблудия.
А в ассемблере все прямо и честно - и о зависимости от платформы следования байтов в 32-разрядном целом, и не только данные, но и команды известной длины, заодно известно, сколько тактов занимает выполнение команд. Без шаманства и словоблудия.
когда разрабатывают обмен по последовательному стыку, обычно договариваются - первым передается старший байт, или младший. Отплясывая от этого, разработчик на каждом конце уже собирает данные в кучу.
Используя эту договоренность, в Си/С++ можно разрабатывать функции обмена не зная, в каком порядке хранятся байты в памяти.
//если старший передается первым
__int8 input_buffer[BUFFER_SIZE];
__int32 rx_data[BUFFER_SIZE/4]
...
for (int i = 0; BUFFER_SIZE / 4; i++)
{
rx_data[ i /**/ ] =
(input_buffer[4 * i + 0]
Используя эту договоренность, в Си/С++ можно разрабатывать функции обмена не зная, в каком порядке хранятся байты в памяти.
//если старший передается первым
__int8 input_buffer[BUFFER_SIZE];
__int32 rx_data[BUFFER_SIZE/4]
...
for (int i = 0; BUFFER_SIZE / 4; i++)
{
rx_data[ i /**/ ] =
(input_buffer[4 * i + 0]
Гы. И чем этот код отличается от ассемблерного?
Особенно если определить соответствующие макросы и разнести на отдельные строчки...
Особенно если определить соответствующие макросы и разнести на отдельные строчки...
а тем, что меня абсолютно не заботит, на чем он будет исполняться - на сигнальном процессоре, микроконтроллере, или x86 платформе.
А теперь еще раз, после второй строчки: "особенно если определить макросы..." это те самые, которые закрывают мнемонику конкретного Asm: "Clr", "Mov" и т.д.... про именованные области данных тоже "не проблема"...
Ну, и?
Ну, и?
мсье-теоретег tolstopuz знает толк в извращениях.
не вижу смысла спорить с бредом.
не вижу смысла спорить с бредом.
"особенно если определить макросы..." это те самые, которые закрывают мнемонику конкретного AsmИ получить на выходе С
когда разрабатывают обмен по последовательному стыку, обычно договариваются - первым передается старший байт, или младший. Отплясывая от этого, разработчик на каждом конце уже собирает данные в кучу.Интересно, сколько раз си-шник будет гонять по порту байты от младшего к старшему (0,1,2,3) или от старшего к младшему (3,2,1,0), добиваясь, чтобы его прога сама учла смешанный порядок (2,3,0,1), хранения байтов четырехбайтного слова "не зная, в каком порядке хранятся байты в памяти."
Используя эту договоренность, в Си/С++ можно разрабатывать функции обмена не зная, в каком порядке хранятся байты в памяти.
...
никакой зависимости ни от компилятора, ни от аппаратной части.
скажите, а вы также как и tolstopuz - великий теоретик, написавший одну программу много-много лет назад?
ТОП 5
1
2
3
4