когда нужно знание ассемблера?

Речь о структурном программировании, если что. Это языки высокого уровня (Си, как минимум).

Сделать аналог «структурной» управляющей конструкции из примитивов очень просто. Но если эти конструкции уже есть в языке, необходимо использовать их, а не велосипедить свои из примитивов. Поэтому и «goto considered harmful».

(гопниктоном)А ты читал?

когда нужно знание ассемблера? (комментарий)

Инструкция LOOP — это аналог цикла do .. while (--i), т. е. частного случая.

Кого? То самое письмо Дейкстры? Нет, не читал.

прочти, ибо оно не только и не столько о «структурном»

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

repeat Threaded Code James R. Bell (3 page)

но статья больше о ограничености возможностей(охвата процесса) человека

В смысле «программы нужно писать так, чтобы программист смог осознать, что там происходит»? Это и так понятно.

Конечно, относится. Вычисляемое выражение является частью if-statement.

аргументируй :)

или цитату из стандарта С или С++ приведи

http://www.vspu.ac.ru/~chul/dijkstra/goto/goto.htm

Всё это сахар. Настоящим джедаям нужны только 3 инструкции для Тюринг-полного процессора:

• MOV
• JNZ
• DEC

ref:

• http://en.wikipedia.org/wiki/One_instruction_set_computer
• https://github.com/jbangert/trapcc

Угу. Почему же тогда (например) ядро Linux пишут на высокоуровневом Си, а не на каком-нибудь кроссплатформенном языке ассемблера типа LLVM IR?

Возможно потому что у Линуса не было машины времени сгонять из 1991 в 2000, а там кто его знает, этот just for fan. Слуш, а ты вообще под чем ?

N3337 параграф 6.4 «Selection Statements» абзац 1

Надеюсь, ты умеешь читать формальную грамматику.

Я где-то с этим спорил?

Мой исходный тезис:

«В учебниках» запрещают goto, потому что есть более высокоуровневые управляющие конструкции (см. «структурное программирование»). А в машинных языках таких конструкций нет, поэтому их приходится реализовывать вручную при помощи условных и безусловных переходов.

там 2 страницы(в англ варианте) проще прочитать чем ...

Аналогичный вопрос к тебе.

Тогда спрошу по-другому: почему же тогда был придуман язык Си, а не какой-нибудь кроссплатформенный язык ассемблера?

repeat repeat:

Threaded Code James R. Bell (3 page)

зы. печаль когда новечкам сообщают про интерпретаторы и компиляторы редко(никогда?) когда упоминают технику из статьи.

LODSW

JMP AX

Потому что assembler — это язык конкретного процессора. И их, этих assembler'ов over9000.

Так вышло, что C — это cross-assembler. Язык достаточно высокоуровневый, что бы абстрагироватся от машины. И достаточно низкоуровневый, что бы быть безпроблемно переведённым в язык этой самой машины.

википедия-здесь, http://wikipedia.org
гугль - тут, http://google.com

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

Указанными сервисами я пользоваться прекрасно умею. Если ты ещё не понял, я пытаюсь получить от тебя доказательство того, что «асм удобоварим и дружелюбен» (видимо, в сравнении с другими языками, потому что контекст дискуссии именно таков).

Кену Томпсону потребовальс перенести его систему которой пользовалась его группа иследования на другую железку , он предпочёл взять на тот момент поделку Д.Ричи , по мере переноса и эксплуатации С чутка перестал быть совсем уж ассемблером.

посмотри на коментарии лиона и сырцы vhttp://minnie.tuhs.org/cgi-bin/utree.pl

одно только

struct p{int}

дорого стоит

Я спросил — почему Си, а не какой-нибудь кроссплатформенный ассемблер(-like)?

Язык, отвечающий требованию «cross-assembler», может быть гораздо более низкоуровневым. Но почему-то Си именно таков, каким мы его наблюдаем.

по мере переноса и эксплуатации С чутка перестал быть совсем уж ассемблером

Во. Получается, программистам удобнее работать с высокоуровневым языком, чем с ассемблероподобным. ЧТД.

http://v6.cuzuco.com/ посмотри

он и был на тот момент ассемблером с фигурными скобками.

Selection statements choose one of several flows of control.
selection-statement:
if ( condition ) statement
if ( condition ) statement else statement
switch ( condition ) statement
condition:
expression
attribute-specifier-seq opt decl-specifier-seq declarator = initializer-clause
attribute-specifier-seq opt decl-specifier-seq declarator braced-init-list

и где по твоему тут сказано, что condition - это часть if-statement?

if от выражения внутри скобок не зависит, только от его результата, следовательно считать его частью if() неправильно и вообще намекает на отсутствие у тебя абстрактного мышления

ассемблером с фигурными скобками

Вот именно, что «с фигурными скобками». Это уже важное отличие в сторону структурности и всего такого.

Hint: почитай про историю операторов '++' и '--' — это прямые кальки PDP ассембрера. Тем то и был хорош C, что без всяких хитрых оптимизаций ложился 1:1 на PDP asm. Потом оказалось, что и на другие asm.

Я специально отметил — надеюсь, ты умеешь читать (Р)БНФ. Ок, значит, не умеешь. Жаль тебя.

Во. Получается, программистам удобнее работать с высокоуровневым языком, чем с ассемблероподобным. ЧТД.

Здрасте, Капитан! ;) Конечно удобней.

Ещё раз. Язык, отвечающий этим требованиям, мог быть каким угодно, вплоть до отсутствия compound expressions. Однако же.

Ну а там вверху товарищ handbrake доказывал, что высокоуровневые языки и структурное программирование — нинужно, потому что «Асм, как и линь - очень удобоварим и дружелюбен».

про ++ и — это заблуждение что утащено с pdp ( и конкретно pdp11) на беллабовских страницах есть о этом(опровержение заблуждения)

http://cm.bell-labs.com/who/dmr/chist.html

забавно там же есть ссылка на шитый код как метод реализации интерпретатора B

в этом документе БНФ не используется

да не был первоС структурным.

поэтому там по началу было слово auto для пометки что переменая локальна.

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

Мотоцикл «Восход» кусок железа не только для дикаря.

То, что используется в стандарте C++, отличается от РБНФ только «управляющими» символами.

Каждый нетерминальный символ состоит из одного или более терминальных и/или нетерминальных символов, сочетание которых определяется правилами грамматики

Состоит из

Я не говорю, что он был целиком структурным в современном понимании этого слова. Тенденция заметна, понимаешь?

Кому и brainf*ck невеста. ;)

Я о другом. Конкретней, что высокоуровневые языки (в частности C) — это суть cross-assembler с кучей удобного сахара.

Возвращаясь к исходному вопросу: знание — очень желательно, использование — очень не желательно.

PS: С другой стороны, ныряния во все эти ассемблеры — неплохая зарядка для ума. (А у меня вот есть своя собственная имплементация для DCPU16. ☺)

Конкретней, что высокоуровневые языки (в частности C) — это суть cross-assembler с кучей удобного сахара.

А кто-то спорит? Только вот сахар очень сильнодействующий. На много слоёв абстракций.

А у меня вот есть своя собственная имплементация для DCPU16. ☺

Хех. А я пилил свой игрушечный стековый процессор с just-in-time трансляцией в x86_64.

да нифига.

вот за экспонируй:

в начале 60ых реализуют лиспик(святой Расел) где контексты функций были в списках - как следствие динамическое связывание.

в это же время некто https://ru.wikipedia.org/wiki/Стек#cite_note-2

(1957) идея очевидности и обязательности стековой организации не была так уж ясна. это теперь у кого образование тем стек ествественнен.

тот же пример пхп-кухарок которым стек рокетсцаенс , ну или js с его списком(деревом) контекстов(что то это напоминает )

так что тенденции нет.

Накроман и ассемблер. Васм напомнило.

производительность узкого места не?

Если ты напишешь пузырьковую сортировку на ассемблере, она не станет от этого быстрее.

Подсказка в виде задачи: на входе дан большой объем однотипных данных, необходимо отыскать в нем нужное тебе значение.

Как будешь решать?

производительность узкого места не?

KISS. Надо не кровати двигать, а алгоритм менять.

PS: а за «оптимизации» на asm, вообще делать выговор на собрании разработчиков! (Портабельность выше оптимизации.)

• make it work
• make it right
• make it fast

И только в этой последовальности.

beastie

производительность узкого места не

подразумева(ю|л)(машина времени свидетель)

осознание в какой машкод транслируется то или иное.

Но почему-то Си именно таков, каким мы его наблюдаем.

Потому что опускаясь ниже, профита не будет вплоть до асма, а гемора будет прибавляться значительно. Си - тот минимально разумный уровень, когда мы можем не жертвовать слишком многим, получая при этом удобство относительно высокоуровневого языка.

Это какая-то очень изощрённая техника кодогенерации?

Раньше многое так писалось, особенно трансляторы, особенно какие-нибудь бейсики-форты с JIT.

так код получается быстрым и вообще оптимальным

Так код получается _плотным_. Скорости это давало чуть и довольно редко. Ну а сегодня обилие переходов делает эту технику неактуальной на мощном железе.

Ну а там вверху товарищ handbrake доказывал, что высокоуровневые языки и структурное программирование — нинужно, потому что «Асм, как и линь - очень удобоварим и дружелюбен».

Во. Получается, программистам удобнее работать с высокоуровневым языком, чем с ассемблероподобным. ЧТД.

1. Приведи, где я сказал «нинужно»
2. «линукс очень дружелюбен, он просто тщательно выбирает друзей», ваш КО.
3. Удобство - понятие субъективное, и будь тогда LLVM, кто его знает, на чем писали бы ядра, особенно при том железе и jff.

Хех. А я пилил свой игрушечный стековый процессор с just-in-time трансляцией в x86_64.

А я кодил лет ~10 начиная с собственных ОС для 6502 и PM kernel для x86 и кончая кросс-субд UML прикладухой писанной на самой себе.
ТС вообще-то спрашивал о практической необходимости знания асма. Асм знать надо, даже SQL запросы потом до него дотранслируются. Знаешь асм - знаешь во что превратятся любые конструкции любого высокоуровневого языка. То что асм разный не отменяет того, что как минимум 50% базовых мнемоник на всех процах будут схожими.

Слуш, серьезно, разупорись, ты чужие слова понимаешь совершенно произвольным убразом.

когда нужно знание ассемблера?

Всегда. Еще стоит поиграть с компиляцией -> дизасмом, чтобы представлять себе кодогенерацию.

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