Что лучше учить: Java или Assembler?
Каковы вообще перспективы у ассемблера?У которого?
>Каковы вообще перспективы у ассемблера?
embedded, разработка ядра какой-н ОС.
embedded, разработка ядра какой-н ОС.
Знаю С++, WINAPI, немного РНР. С последним деятельность свою связывать не собираюсь. Что лучше для дальнейшей полезности с точки зрения легкости трудоустройства и зарплат учить? Каковы вообще перспективы у ассемблера?рекомендую забить на проганье. займись танцами, или может из тебя выйдет хороший психоаналитик
Понимаю, что РНР не сильно связан со всем остальным.
Ой, ты такой клевый, фанат разных компиляторов, да? Сидишь на баше с утра до вечера и часами готов рассказывать девушке анекдоты про сисадминов, нет?
А мне это все не нужно, начальство довольно моей работой и прекрасно знает о том, как я ко всему отношусь. Все, что мне дают делать, я делаю в срок, этого достаточно. И учу технологии не из интереса, а исходя из их применения при трудоустройстве.
Все, извини, я уже доделал все, что хотел, споки ноки .
Сейчас бойцы сетевого фронта начнут минусами атаковать
Ой, ты такой клевый, фанат разных компиляторов, да? Сидишь на баше с утра до вечера и часами готов рассказывать девушке анекдоты про сисадминов, нет?
А мне это все не нужно, начальство довольно моей работой и прекрасно знает о том, как я ко всему отношусь. Все, что мне дают делать, я делаю в срок, этого достаточно. И учу технологии не из интереса, а исходя из их применения при трудоустройстве.
Все, извини, я уже доделал все, что хотел, споки ноки .
Сейчас бойцы сетевого фронта начнут минусами атаковать
Что лучше для дальнейшей полезности с точки зрения легкости трудоустройства и зарплат учить?Основы управления проектами.
Java
учись лучше кафель класть.
А мне это все не нужнот.е. ты собираешься потратить 2/3 своей жизни на то, что тебе неинтересно?
ps
24 часа в сутки - 8 часов сон, 4 часа - бытовуха, 8 часов - работа
итого: 24-8-4 = 12, 8/12 = 2/3
А я-таки отвечу по теме 
Изучи ассемблер, а то порой уныло видеть программиста, который не знает как устроен комп хотя бы на этом уровне.
Ответ, ессно, не тебе, но тому, кому интересно.
Изучи ассемблер, а то порой уныло видеть программиста, который не знает как устроен комп хотя бы на этом уровне.
Ответ, ессно, не тебе, но тому, кому интересно.
если программист будучи программистом не знает как комп устроен на этом уровне ..хм. плохо конечно, но если он при этом уже получает 100 000р в месяц то ничего страшного
если это так, то ты прав.
А если нет?
А если нет?
Учи 1С 
> Изучи ассемблер, а то порой уныло видеть программиста,
> который не знает как устроен комп хотя бы на этом уровне.
Чем знание ассемблера лучше знания того же паскаля или сей
в этом отношении?
---
...Я работаю антинаучным аферистом...
> который не знает как устроен комп хотя бы на этом уровне.
Чем знание ассемблера лучше знания того же паскаля или сей
в этом отношении?
---
...Я работаю антинаучным аферистом...
Чем знание ассемблера лучше знания того же паскаля или сейДа, смотреть на дотнетчиков, которые на сях или паскале не писали еще более страшно, наверное. Благо, с такими встречаться не приходилось.
в этом отношении?
Чтобы C, а тем более C++ хорошо понимать знание ассемблера тоже очень кстати.
Хотя бы понимать, что такое стек на самом деле, как происходит вызов функции и возврат. Только этим, как мне сейчас кажется и отличается C от ассемблера (не считая макросов там всяких).
Если же говорить о C++, исключениях, автоматических объектах и других радостях ООП, то там еще больше интересного, хотя здесь уже все опционально, конечно. Я говорил о базовом знакомстве. Ну, скажем, научиться на асме написать какой-нибудь qsort.
У тебя же где-то в цитатах было "Narrowness of experience leads to narrowness of imagination." (//как раз нашел в ответе мне так вот высококлассный специалист обязан знать ассемблер хотя бы на базовом уровне. Какой-нибудь 386.
так вот высококлассный специалист обязан знать ассемблер хотя бы на базовом уровне. Какой-нибудь 386.вместо этого лучше заботать IL(как современный пример стековой машинки или может быть даже Форт (как классический пример стековой машинки)
Чем лучше-то? Я так и не понял.
> Да, смотреть на дотнетчиков, которые на сях или паскале не
> писали еще более страшно, наверное.
Смотреть на Makefile, писанный насильником ещё больнее.
> Хотя бы понимать, что такое стек на самом деле, как происходит
> вызов функции и возврат. Только этим, как мне сейчас кажется и
> отличается C от ассемблера (не считая макросов там всяких).
Это всё неправда.
Очевидно, ты никогда не видел кода, сделанного хорошим оптимизатором.
> Я говорил о базовом знакомстве.
> Ну, скажем, научиться на асме написать какой-нибудь qsort.
Вот это уже совсем бесполезное дело. Зачем его писать на ассемблере?
Какие выгоды это даст за исключением "просто выучить"?
> так вот высококлассный специалист обязан знать ассемблер хотя бы
> на базовом уровне. Какой-нибудь 386.
Какой смысл всё это знать, если только очень высококлассный
специалист может написать код лучше созданного оптимизатором?
Какой смысл учить те неэффективные команды, которые в 80386
были только для совместимости со старьём? Для того, чтобы ещё
раз повторить это? Какой смысл учить все эти трюки с очисткой
регистров, если оптимизатор сделает это за тебя?
Любой высококлассный специалист скажет тебе, что всё это ерунда,
нужная только в узких областях системного программирования и
компиляторостроения.
---
"An empty head is not really empty; it is stuffed with rubbish.
Hence the difficulty of forcing anything into an empty head."
> писали еще более страшно, наверное.
Смотреть на Makefile, писанный насильником ещё больнее.
> Хотя бы понимать, что такое стек на самом деле, как происходит
> вызов функции и возврат. Только этим, как мне сейчас кажется и
> отличается C от ассемблера (не считая макросов там всяких).
Это всё неправда.
Очевидно, ты никогда не видел кода, сделанного хорошим оптимизатором.
> Я говорил о базовом знакомстве.
> Ну, скажем, научиться на асме написать какой-нибудь qsort.
Вот это уже совсем бесполезное дело. Зачем его писать на ассемблере?
Какие выгоды это даст за исключением "просто выучить"?
> так вот высококлассный специалист обязан знать ассемблер хотя бы
> на базовом уровне. Какой-нибудь 386.
Какой смысл всё это знать, если только очень высококлассный
специалист может написать код лучше созданного оптимизатором?
Какой смысл учить те неэффективные команды, которые в 80386
были только для совместимости со старьём? Для того, чтобы ещё
раз повторить это? Какой смысл учить все эти трюки с очисткой
регистров, если оптимизатор сделает это за тебя?
Любой высококлассный специалист скажет тебе, что всё это ерунда,
нужная только в узких областях системного программирования и
компиляторостроения.
---
"An empty head is not really empty; it is stuffed with rubbish.
Hence the difficulty of forcing anything into an empty head."
> Чем лучше-то?
Например, тем, что Форт сильно отличается от многого остального,
и ты можешь изучить совсем другие приёмы мышления.
Что касается IL или яванского байт-кода, это то же самое, что ты
хочешь протащить как пользу знания архитектуры реальной машины.
---
"Narrowness of experience leads to narrowness of imagination."
Например, тем, что Форт сильно отличается от многого остального,
и ты можешь изучить совсем другие приёмы мышления.
Что касается IL или яванского байт-кода, это то же самое, что ты
хочешь протащить как пользу знания архитектуры реальной машины.
---
"Narrowness of experience leads to narrowness of imagination."
Что касается IL или яванского байт-кода, это то же самое, что тыТ.е. лучше то же самое, но не то, что я посоветовал.
хочешь протащить как пользу знания архитектуры реальной машины.
Я просто сказал, что полезно понимать, как работает комп. Для этого написать хоть что-нибудь на асме. Я писал что-то на асме, несколько моих коллег на работе — не писали. Они иногда удивляются, как это я "угадываю" как поведет себя спорный код, написанный на плюсах. Я лишь об этом.
КОНТРА говорит, что какое-то знание будет лишним получить, я удивлен.
КОНТРА говорит, что какое-то знание будет лишним получить, я удивлен.
Чем лучше-то? Я так и не понял.Что такое ассемблер x386? фактически это команды вида:
$a = p1;
$a = $b + $c;
p2 = $a;
где $a, $b, $c - это какие-то спец. переменные (регистры а переменные - p1,p2 - это "обычные" переменные размещенные в памяти.
но все эти операции программист еще выучил когда программировал, хоть на паскале, хоть на .net-е, хоть на php.
соответственно, изучение ассемблера x386 фактически сведется к зубрежке ненужных буквочек.
ps
изучение стекового языка дает намного больше: во-первых, меняет парадигму, что очень полезно при развитии, во-вторых, лучше учит (чем те же регистры) умению работать с ограниченным набором объектов(верхушки стека) доступных для манипулирования
Я не спорю, что можно поизучать функциональные языки, скажем, для развития, для изучения новых парадигм. Я говорил о другом: пишешь на C++ — желательно знать свою платформу. Хотя бы на базовом уровне. Что лучше — не очевидно.
Что учитьЗависит от твоих целей.
Если хочешь быть быдлокодером - php и Ко тебе в руки. Но дальше написания Гуй- и Веб-морд сложно уйти. Хотя - платят обычно хорошо.
Из вопроса следует, что ты не знаешь, чем ты будешь заниматься и хочешь учить язык из интереса (иначе как могли попасть в один список асм и java?).
Хороший программист должен знать разные языки и парадигмы, т.к. изучение языка, сильно непохожего на уже выученные, меняет способ мышления.
Имеет смысл выучить функциональную (haskell, lisp объектно-ориентированную (smalltalk, lisp clos, но не c++ или java стековую (forth) парадигмы, чё-нить скриптовое (perl, bash или python ну и ассемблер несомненно, очень полезен.
В числе первых, возможно, стоит посмотреть на lisp. Он переворачивает мышление, заставляет смотреть на привычные вещи с другой стороны. После него другие языки изучаются быстро и без проблем. Хотя, работу с ним оччень нелегко найти.
PS. выучить - я имел ввиду не зубрить по ч0рному, а более-менее подробно ознакомиться.
Познакомившись с каждым языком, дальше самому выбрать то, что по душе
>> Что касается IL или яванского байт-кода, это то же самое, что ты
>> хочешь протащить как пользу знания архитектуры реальной машины.
> Т.е. лучше то же самое, но не то, что я посоветовал.
Лично я считаю знание IL ещё более бесполезным.
Это область чисто техническая, навроде элементной базы.
---
...Я работаю антинаучным аферистом...
>> хочешь протащить как пользу знания архитектуры реальной машины.
> Т.е. лучше то же самое, но не то, что я посоветовал.
Лично я считаю знание IL ещё более бесполезным.
Это область чисто техническая, навроде элементной базы.
---
...Я работаю антинаучным аферистом...
иначе как могли попасть в один список асм и java?вариант "тролль" ты не хочешь рассматривать?
понимать как устроен компьютер != знать ассемблер
причем совсем неравно.
можно знать ассемблер, но не понимать как работает компьютер
можно понимать как устроен компьютер, но не знать ассемблер.
зы
имхо, на понимание работы компьютера лучше давать задачки на экстремальную оптимизацию вида:
1. на скрипте добиться обсчета за минуту как можно большего кол-ва цифр в числе pi
2. на .net-е за минуту обработать как можно больше символов из файла
и т.д.
такое на асме может каждый дурак быстро сделать, а вот попробуй тоже самое сделать на верхнем уровне...
сразу приходиться разбираться как что устроено.
причем совсем неравно.
можно знать ассемблер, но не понимать как работает компьютер
можно понимать как устроен компьютер, но не знать ассемблер.
зы
имхо, на понимание работы компьютера лучше давать задачки на экстремальную оптимизацию вида:
1. на скрипте добиться обсчета за минуту как можно большего кол-ва цифр в числе pi
2. на .net-е за минуту обработать как можно больше символов из файла
и т.д.
такое на асме может каждый дурак быстро сделать, а вот попробуй тоже самое сделать на верхнем уровне...
сразу приходиться разбираться как что устроено.
> КОНТРА говорит, что какое-то знание будет лишним получить, я удивлен.
Удивляйся дальше.
Я говорил не о том, что оно лишнее, а о том, что оно не настолько полезное,
как ты считаешь. Своё время ты можешь провести как угодно, но когда тебя
спрашивают, как его проводить, лучше советовать более полезный способ.
Если конкретно, то изучение явы более эффективно профессионально.
---
...Я работаю антинаучным аферистом...
Удивляйся дальше.
Я говорил не о том, что оно лишнее, а о том, что оно не настолько полезное,
как ты считаешь. Своё время ты можешь провести как угодно, но когда тебя
спрашивают, как его проводить, лучше советовать более полезный способ.
Если конкретно, то изучение явы более эффективно профессионально.
---
...Я работаю антинаучным аферистом...
А ты знаешь, как я считаю? Просто сказал, что не повредит и что хороший программист должен иметь представление как минимум.
>> Что такое ассемблер x386? фактически это команды вида:
Нет, не такого вида. Не бывает трёх регистров в одной команде. Кроме того, x86 — далеко не RISC-машина, поэтому загрузки и выгрузки в явном виде нет. Не надо писать того, чего не знаешь, хоть ты и умный.
Для того, чтобы нормально писать на x86-ассемблере, недостаточно знания самого ассемблера. Там конвейер весьма сложный сейчас, и чтобы что-то делать эффективно, надо хотя бы примерно себе представлять, что и как в нём работает.
>> изучение ассемблера x386 фактически сведется к зубрежке ненужных буквочек
Возможно, но совершенно неясно, чем это отличается от того же IL. И то, и другое — ISA, то есть набор ненужных буквочек. Вот только если с IL всё понятно в плане того, что и когда попадает на стек (хотя бы в некоторой погрешности в x86 всё гораздо сложнее. Кто из вас сходу скажет, в какое количество ассемблерных инструкций x86 (я уж не говорю про количество тактов) оттранслируется выражение на C?
Я, пожалуй, ещё так сформулирую свою позицию: ассемблер — это вообще не язык. Язык — это ISA, ассемблер — способ кодировки. Поэтому "учить ассемблер" в моём понимании — это что-то странное. А вот изучать современные архитектуры можно годами, и всё равно полностью в голову не уложить.
Кто из вас (простите за повторение) может написать простенький гипервизор?
>> изучение стекового языка дает намного больше: во-первых, меняет парадигму, что очень полезно при развитии, во-вторых, лучше учит (чем те же регистры) умению работать с ограниченным набором объектов(верхушки стека) доступных для манипулирования
Ну это вообще комментировать не хочется. Мало того, что FPU в x86 организован как стек, так ещё и парадигма никакая не меняется. Что в одном случае программирование в ограничениях, что в другом. Какая, блин, разница. Стек удобен для оптимизаций, а нормальному низкоуровневому программисту должно быть пофиг.
Пардоньте за простыню, был взволнован.
Нет, не такого вида. Не бывает трёх регистров в одной команде. Кроме того, x86 — далеко не RISC-машина, поэтому загрузки и выгрузки в явном виде нет. Не надо писать того, чего не знаешь, хоть ты и умный.
Для того, чтобы нормально писать на x86-ассемблере, недостаточно знания самого ассемблера. Там конвейер весьма сложный сейчас, и чтобы что-то делать эффективно, надо хотя бы примерно себе представлять, что и как в нём работает.
>> изучение ассемблера x386 фактически сведется к зубрежке ненужных буквочек
Возможно, но совершенно неясно, чем это отличается от того же IL. И то, и другое — ISA, то есть набор ненужных буквочек. Вот только если с IL всё понятно в плане того, что и когда попадает на стек (хотя бы в некоторой погрешности в x86 всё гораздо сложнее. Кто из вас сходу скажет, в какое количество ассемблерных инструкций x86 (я уж не говорю про количество тактов) оттранслируется выражение на C?
Я, пожалуй, ещё так сформулирую свою позицию: ассемблер — это вообще не язык. Язык — это ISA, ассемблер — способ кодировки. Поэтому "учить ассемблер" в моём понимании — это что-то странное. А вот изучать современные архитектуры можно годами, и всё равно полностью в голову не уложить.
Кто из вас (простите за повторение) может написать простенький гипервизор?
>> изучение стекового языка дает намного больше: во-первых, меняет парадигму, что очень полезно при развитии, во-вторых, лучше учит (чем те же регистры) умению работать с ограниченным набором объектов(верхушки стека) доступных для манипулирования
Ну это вообще комментировать не хочется. Мало того, что FPU в x86 организован как стек, так ещё и парадигма никакая не меняется. Что в одном случае программирование в ограничениях, что в другом. Какая, блин, разница. Стек удобен для оптимизаций, а нормальному низкоуровневому программисту должно быть пофиг.
Пардоньте за простыню, был взволнован.
> Просто сказал, что не повредит и что хороший программист
> должен иметь представление как минимум.
Я не согласен с этим "должен," оно, по самой меньшей мере, спорно.
Есть и другие причины, почему в данном случае следует советовать яву,
а не ассемблер.
---
"Я знаю правду! Все прежние правды --- прочь!"
> должен иметь представление как минимум.
Я не согласен с этим "должен," оно, по самой меньшей мере, спорно.
Есть и другие причины, почему в данном случае следует советовать яву,
а не ассемблер.
---
"Я знаю правду! Все прежние правды --- прочь!"
>> Что такое ассемблер x386?
> Не бывает трёх регистров в одной команде.
Наглая ложь.
> Кроме того, x86 — далеко не RISC-машина, поэтому загрузки и
> выгрузки в явном виде нет.
> Не надо писать того, чего не знаешь, хоть ты и умный.
Давай, ты не будешь делать такие глупые ошибки, когда указываешь на ошибки.
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
> Не бывает трёх регистров в одной команде.
Наглая ложь.
> Кроме того, x86 — далеко не RISC-машина, поэтому загрузки и
> выгрузки в явном виде нет.
> Не надо писать того, чего не знаешь, хоть ты и умный.
Давай, ты не будешь делать такие глупые ошибки, когда указываешь на ошибки.
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
Если что, операнды инструкции кодируются через ModR/M (upd: уточняю для особо старательных: а также, возможно, SIB, а также, возможно, смещения который предусматривает регистр + память или регистр + регистр. Если ты мне покажешь инструкцию, где три операнда-регистра, я буду очень удивлён.
Т.е. ты советуешь _не_ изучать ассемблер и изучать java. Так выходит?
Да, с точки зрения дальнейшего трудоустройства может оказаться
более выгодным изучать какой-нибудь питон.
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
более выгодным изучать какой-нибудь питон.
---
"Для того, чтобы не пройти мимо цели, иногда необходимо пойти ко дну."
Смотреть на Makefile, писанный насильником ещё больнее.На .asd смотреть намного приятнее? Или нужно смотреть на Makefile написанный кем-нибудь другим?
>> Смотреть на Makefile, писанный насильником ещё больнее.
> На .asd смотреть намного приятнее?
Человек, пишущий файл для ASDF, как правило знает
о существовании других парадигм помимо императивной.
> Или нужно смотреть на Makefile написанный кем-нибудь другим?
Да. Надо понимать, что make не sh.
---
"This user is BSD-compliant."
> На .asd смотреть намного приятнее?
Человек, пишущий файл для ASDF, как правило знает
о существовании других парадигм помимо императивной.
> Или нужно смотреть на Makefile написанный кем-нибудь другим?
Да. Надо понимать, что make не sh.
---
"This user is BSD-compliant."
в моем понимании, это уже профессиональная деградация, когда человек начинает строить безапеляционные рассуждения вида - что в байте 8 бит, и по другому не бывает.
т.е. очень фатально - когда профессионал начинает думать в терминах ограничений (а не возможностей) тех инструментов с котороыми он привык работать.
будет тот самый $a=$b+$c
> Кто из вас (простите за повторение) может написать простенький гипервизор?
вроде это делается одной командой, разве нет?
ps
а если серьезно, то думаю имея желания, документацию и такую-то матерь - за пару вечеров беспроблем напишется.
т.е. очень фатально - когда профессионал начинает думать в терминах ограничений (а не возможностей) тех инструментов с котороыми он привык работать.
Нет, не такого вида. Не бывает трёх регистров в одной команде. Кроме того, x86 — далеко не RISC-машина, поэтому загрузки и выгрузки в явном виде нет. Не надо писать того, чего не знаешь, хоть ты и умный.как минимум lea eax, [ebx+ecx],
будет тот самый $a=$b+$c
> Кто из вас (простите за повторение) может написать простенький гипервизор?
вроде это делается одной командой, разве нет?
Process.Start("vmware.exe");
ps
а если серьезно, то думаю имея желания, документацию и такую-то матерь - за пару вечеров беспроблем напишется.
>> как минимум lea eax, [ebx+ecx]
Это не $a = $b + $c всё-таки. Оно принципиально по-другому проходит по конвейеру. И трёх регистров здесь так-таки нет, один регистр и одна память, косвенно адресуемая.
>> вроде это делается одной командой, разве нет
К вопросу об ограничениях. Кроме vmware других не бывает гипервизоров? А принципиально других задач для них? Чтобы было понятнее, приведу один пример: эмуляция отсутствующего оборудования (TPM-чип). Что для этого надо написать в Process.Start?
>> имея документацию
Вот именно. Только in soviet Russia документация имеет тебя. Без того, чтобы хорошо разбираться в других частях платформы, бесполезно даже пытаться начинать читать доку по SVM (а уж по VT так и вовсе). Я уж молчу о том, что там полно ошибок.
Это не $a = $b + $c всё-таки. Оно принципиально по-другому проходит по конвейеру. И трёх регистров здесь так-таки нет, один регистр и одна память, косвенно адресуемая.
>> вроде это делается одной командой, разве нет
К вопросу об ограничениях. Кроме vmware других не бывает гипервизоров? А принципиально других задач для них? Чтобы было понятнее, приведу один пример: эмуляция отсутствующего оборудования (TPM-чип). Что для этого надо написать в Process.Start?
>> имея документацию
Вот именно. Только in soviet Russia документация имеет тебя. Без того, чтобы хорошо разбираться в других частях платформы, бесполезно даже пытаться начинать читать доку по SVM (а уж по VT так и вовсе). Я уж молчу о том, что там полно ошибок.
IL(как современный пример стековой машинкиил разве стековый?
а ты не дашь ссылку на каки-нить описания IL-машины в целом, чтоб из них можно было понять "соль", как там на уровне ила стыковки со сборщиком мусора сделаны и прочее?
> ил разве стековый?
А какой? Регистровый?
---
...Я работаю антинаучным аферистом...
А какой? Регистровый?
---
...Я работаю антинаучным аферистом...
> Это не $a = $b + $c всё-таки. Оно принципиально по-другому
> проходит по конвейеру. И трёх регистров здесь так-таки нет,
> один регистр и одна память, косвенно адресуемая.
Это вопрос терминологии. Есть прямой аналог в химической кинетике:
вопрос механизма тримолекулярных (и более) реакций.
То, как это проходит по конвейеру, на местность операций не влияет,
это чисто техническое решение, к логике отношения не имеющее.
---
...Я работаю антинаучным аферистом...
> проходит по конвейеру. И трёх регистров здесь так-таки нет,
> один регистр и одна память, косвенно адресуемая.
Это вопрос терминологии. Есть прямой аналог в химической кинетике:
вопрос механизма тримолекулярных (и более) реакций.
То, как это проходит по конвейеру, на местность операций не влияет,
это чисто техническое решение, к логике отношения не имеющее.
---
...Я работаю антинаучным аферистом...
напрмер
железных-то стековых архитектур считай что нет и не предвидится, поэтому мне кажется было бы логичным в иле придерживаться той же парадигмы, т.к. каких-то собсвенных удобств от стековости я не вижу.
железных-то стековых архитектур считай что нет и не предвидится, поэтому мне кажется было бы логичным в иле придерживаться той же парадигмы, т.к. каких-то собсвенных удобств от стековости я не вижу.
> железных-то стековых архитектур считай что нет и не предвидится
Правильнее считать, что ты не в теме.
> каких-то собсвенных удобств от стековости я не вижу.
Ты не видишь, другие видят.
---
"Narrowness of experience leads to narrowness of imagination."
Правильнее считать, что ты не в теме.
> каких-то собсвенных удобств от стековости я не вижу.
Ты не видишь, другие видят.
---
"Narrowness of experience leads to narrowness of imagination."
> Что лучше учить: Java или Assembler?
послушай, ты начал нести бред
послушай, ты начал нести бред
>> Что лучше учить: Java или Assembler?
> послушай, ты начал нести бред
Бред начал нести ты. К исходному вопросу прилагается условие,
которое ты отбросил.
---
"Математика --- это тайная надежда, что допущенное упрощение
сойдёт безнаказанно."
> послушай, ты начал нести бред
Бред начал нести ты. К исходному вопросу прилагается условие,
которое ты отбросил.
---
"Математика --- это тайная надежда, что допущенное упрощение
сойдёт безнаказанно."
> железных-то стековых архитектур считай что нет и не предвидитсяну и какой пример будет?
Правильнее считать, что ты не в теме.
жизненной железной стековой архитектуры, хоть бы перспективной
И трёх регистров здесь так-таки нет, один регистр и одна память, косвенно адресуемая.чего?
после выполнения команды lea eax, [ebx+ecx] в eax будет ebx+ecx
какая нафиг память?
а ты не дашь ссылку на каки-нить описания IL-машины в целом, чтоб из них можно было понять "соль", как там на уровне ила стыковки со сборщиком мусора сделаны и прочее?IL с GC слабо стыкуется.
в том смысле, что в IL-е какой-то особой поддержки gc нет.
единственное важное отличие (которое необходимо для gc) от стандартного ассемблера - это то, что мы всегда точно знаем, с каким типом мы имеем дело: с указателем, числом или чем-то еще.
ps
gc же, например, и для C/C++ есть, но там как раз все упирается в то, что язык плохо различает с чем он работает - с указателем, или числом.
И вот тебе ещё для раздумья:
http://www.spectrum.ieee.org/semiconductors/processors/25-mi...
---
"Narrowness of experience leads to narrowness of imagination."
http://www.spectrum.ieee.org/semiconductors/processors/25-mi...
---
"Narrowness of experience leads to narrowness of imagination."
Кстати, только что осознал, что по ссылке написано про тёплый ламповый звук.
---
"Пограничную ситуацию предугадать невозможно. <...>
Во всех обстоятельствах вы должны помнить --- ноль эмоций."
---
"Пограничную ситуацию предугадать невозможно. <...>
Во всех обстоятельствах вы должны помнить --- ноль эмоций."
Конечно, будет. Только побочные эффекты у lea и у add, мягко говоря, разные.
Говорить, что здесь участвует три регистра, мне кажется неверным. Операнды имеют не ту классификацию, которую ты им придумываешь, а ту, которая реально есть у процессора. Память она и есть память, потому что кодируется, как память, а не как пара регистров.
Продолжать этот спор не вижу смысла. Если кому-то удобно считать, что lea — это такое сложение с немного странным синтаксисом, good for them.
Говорить, что здесь участвует три регистра, мне кажется неверным. Операнды имеют не ту классификацию, которую ты им придумываешь, а ту, которая реально есть у процессора. Память она и есть память, потому что кодируется, как память, а не как пара регистров.
Продолжать этот спор не вижу смысла. Если кому-то удобно считать, что lea — это такое сложение с немного странным синтаксисом, good for them.
А я вот не в теме: сейчас по CX уже можно индексировать стало?
С 386 начиная можно в качестве индекса и базы брать любой из GPR. На x86_64 в том числе расширенные, а также RIP.
Если кому-то удобно считать, что lea — это такое сложение
для тебя может будет сюрпризом, но например компилятор gcc считает именно так
[xoft ~]$ cat lea.cpp
extern "C" int add(int x, int y) {
return x+y;
}
[xoft ~]$ gcc -O3 -S -o lea.asm lea.cpp
[xoft ~]$ head lea.asm
.file "lea.cpp"
.text
.p2align 415
.globl add
.type add, @function
add:
.LFB2:
leal (%rsi,%rdi %eax
ret
.LFE2:
А если без -O3?
при -O1 то же самое. при -O0 он считает себя обязанным завести локальные переменные на стеке получается так
получается так
[xoft ~]$ head -17 lea.asm
.file "lea.cpp"
.text
.globl add
.type add, @function
add:
.LFB2:
pushq %rbp
.LCFI0:
movq %rsp, %rbp
.LCFI1:
movl %edi, -4(%rbp)
movl %esi, -8(%rbp)
movl -8(%rbp %edx
movl -4(%rbp %eax
addl %edx, %eax
leave
ret
Для тебя может будет сюрпризом, но далеко не всегда. Замени x + y на !(x + y > 0) и посмотри, что изменилось. Не могу на 100% гарантировать результат, но дойду до работы — посмотрю.
да я и не говорю, что всегда
просто ты как бы утверждаешь что помимо семантики инструкций (т.е. что происходит при их выполнении) у них еще есть "внутренний смысл" (т.е. в каких случаях ими пользоваться "правильно" а в каких нет). а я считаю что второго понятия не существует. ну точнее мне всё равно существует оно или нет, оно не помогает программировать
причем, если бы речь была о какой-нибудь библиотеке, то я бы с тобой согласился. если пользоваться методами библиотеки не по назначению, то есть отличный шанс отгрести при портировании на другую реализацию библиотеки, или при переходе на другую версию. не у всех хватает сил выдерживать обратную совместимость до мелочей, тем более в неспецифицированных местах. да и понимать твой код будет мягко говоря трудновато. а с ассемблером всё иначе, не могу поверить что кто-то сделает процессор, с такими же инструкциями, но работающими чуть-чуть по-другому и понимать его особо никому не нужно, ну сгенерировали какой-то и забыли. а других причин молиться на "внутренний смысл" я не вижу.
просто ты как бы утверждаешь что помимо семантики инструкций (т.е. что происходит при их выполнении) у них еще есть "внутренний смысл" (т.е. в каких случаях ими пользоваться "правильно" а в каких нет). а я считаю что второго понятия не существует. ну точнее мне всё равно существует оно или нет, оно не помогает программировать
причем, если бы речь была о какой-нибудь библиотеке, то я бы с тобой согласился. если пользоваться методами библиотеки не по назначению, то есть отличный шанс отгрести при портировании на другую реализацию библиотеки, или при переходе на другую версию. не у всех хватает сил выдерживать обратную совместимость до мелочей, тем более в неспецифицированных местах. да и понимать твой код будет мягко говоря трудновато. а с ассемблером всё иначе, не могу поверить что кто-то сделает процессор, с такими же инструкциями, но работающими чуть-чуть по-другому
и понимать его особо никому не нужно, ну сгенерировали какой-то и забыли. а других причин молиться на "внутренний смысл" я не вижу.
-bash-3.2$ cat lea.c; cc -O3 -S lea.c ; cat lea.s
int
add(int x, int y)
{
return x + y;
}
.file "lea.c"
.text
.p2align 415
.globl add
.type add, @function
add:
pushl %ebp
movl %esp, %ebp
movl 12(%ebp %eax
addl 8(%ebp %eax
popl %ebp
ret
.size add, .-add
.ident "GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1.2-44)"
.section .note.GNU-stack,"",@progbits
И вообще, почему у тебя передаются параметры на регистрах? Это кагбэ не cdecl. upd: тьфу, блин, x86_64. Не заметил. Тем не менее, в приведённом мной выше примере всё равно будет ADD.
Да флаги же )
LEA флаги не выставляет, а ADD выставляет.
LEA флаги не выставляет, а ADD выставляет.
Ещё пара дополнений.
>> просто ты как бы утверждаешь что помимо семантики инструкций (т.е. что происходит при их выполнении) у них еще есть "внутренний смысл"
Нет, просто семантику толком многие не знают. У LEA и ADD семантика отличается, например, флагами.
>> не могу поверить что кто-то сделает процессор, с такими же инструкциями, но работающими чуть-чуть по-другому
У Intel, AMD и VIA очень много различий в мелочах. И если для прикладного программиста это именно мелочи, с которыми он никогда и не столкнётся, для низкоуровневого разработчика эти мелочи, как говорится, в рот не влезают.
>> понимать его особо никому не нужно
Многие почему-то полагают, что сейчас на асме уже никто не пишет. Пишут. И надо понимать.
>> просто ты как бы утверждаешь что помимо семантики инструкций (т.е. что происходит при их выполнении) у них еще есть "внутренний смысл"
Нет, просто семантику толком многие не знают. У LEA и ADD семантика отличается, например, флагами.
>> не могу поверить что кто-то сделает процессор, с такими же инструкциями, но работающими чуть-чуть по-другому
У Intel, AMD и VIA очень много различий в мелочах. И если для прикладного программиста это именно мелочи, с которыми он никогда и не столкнётся, для низкоуровневого разработчика эти мелочи, как говорится, в рот не влезают.
>> понимать его особо никому не нужно
Многие почему-то полагают, что сейчас на асме уже никто не пишет. Пишут. И надо понимать.
Еще есть моя любимая команда div r, которая делит eax:edx на r. А также shld r1,r2,cl.
Да, но три нефиксированных регистра не могут являться операндами. Я же к синтаксису у прицепился в первую-то очередь: из его примера следует, что можно как угодно обращаться с регистрами. Так-то и RSM можно в пример привести. Про SHLD согласен, но с ней вообще история мутная, как и со всей 2-й ModR/M-группой.
Вообще мой личный опыт использования ассемблера:
1. На нем достаточно удобно писать маленькие dll-ки для переходников. Не нужно заморачиваться со сложными настройками компиляциями dll'ек. (на паскале создавать dll'ки еще проще, но free pascal из-за неотключаемой инициализации fpu и глюков с TLS не совсем дружит c JNI начиная с java 1.6)
2. Нативные программы иногда отказываются работать в релизе или при добавлении отладочной печати. Окно с ассеблерным кодом в таком случае остается единственным средством отладки. Я не программирую на C++, поэтому с таким не сталкивался, а вот друзьям - приходилось. Слава богу, с Java такой проблемы нет.
3. С помощью низкоуровневого отладчика часто удается понять почему чужая программа совершенно необъяснимо валится с ошибкой и либо устранить то, что ей не нравится, либо исправить в ней ошибку (пару раз бывало и такое).
4. Пару раз оптимизировал код с помощью ассемблерных вставок, но эффект был не больше двухкратного ускорения.
Вообще, важен, конечно, не сам ассемблер, а понимание модели памяти компьютера, цены различных операций, работы кэша, устройство в памяти объектов и кучи, самой программы и ее библиотек, механизм их динамического подключения, принципы работы современных многозадачных ОС. Вот это стоит изучить, если есть время и желание.
1. На нем достаточно удобно писать маленькие dll-ки для переходников. Не нужно заморачиваться со сложными настройками компиляциями dll'ек. (на паскале создавать dll'ки еще проще, но free pascal из-за неотключаемой инициализации fpu и глюков с TLS не совсем дружит c JNI начиная с java 1.6)
2. Нативные программы иногда отказываются работать в релизе или при добавлении отладочной печати. Окно с ассеблерным кодом в таком случае остается единственным средством отладки. Я не программирую на C++, поэтому с таким не сталкивался, а вот друзьям - приходилось. Слава богу, с Java такой проблемы нет.
3. С помощью низкоуровневого отладчика часто удается понять почему чужая программа совершенно необъяснимо валится с ошибкой и либо устранить то, что ей не нравится, либо исправить в ней ошибку (пару раз бывало и такое).
4. Пару раз оптимизировал код с помощью ассемблерных вставок, но эффект был не больше двухкратного ускорения.
Вообще, важен, конечно, не сам ассемблер, а понимание модели памяти компьютера, цены различных операций, работы кэша, устройство в памяти объектов и кучи, самой программы и ее библиотек, механизм их динамического подключения, принципы работы современных многозадачных ОС. Вот это стоит изучить, если есть время и желание.
По всем пунктам согласен )
Я же к синтаксису у прицепился в первую-то очередь: из его примера следует, что можно как угодно обращаться с регистрами.конечно, как угодно.
ограничение на регистры это уже ограничение конкретной железки, а не самого ассемблера.
как пример это подтверждающий: по базовым командам ассемблер x86 и ассемблер современного процессора не отличается, отличается только какие регистры можно или нельзя использовать в командах.
зы
так же ассемблер какого-нибудь z80 не особо отличается от ассемблера x86. все те же самые загрузки в регистры, add/mul и т.д., отличается опять же набором регистров, и какие регистры для чего можно использовать.
WINAPIа это чудо разве используется сейчас?
это ж лоу левел примерно как ассемблер в наше время был, или я ошибаюсь?
Используется, в основном в унаследованном коде, его очень много.
3 регистра в одной команде
lea ebx, [eax+ecx] ; ebx = eax+ecx
Оставить комментарий
Retor
Знаю С++, WINAPI, немного РНР. С последним деятельность свою связывать не собираюсь. Что лучше для дальнейшей полезности с точки зрения легкости трудоустройства и зарплат учить?Каковы вообще перспективы у ассемблера?