Не стоит путать "удивление" и "недопонимание". Написан конкретный вопрос в том, что я могу недопонимать, а не в том, в чём я удивлён. В век цифровой аппаратуры, лично я бы передавал сигнал по широкой шине, где передавались бы и координаты и цвет для данной координаты. Это даст возможность вывода с большей частотой больше информации.
Если есть какая-то конкретная информация, то лучше было поделиться ей, чем разводить демагогию.
Это про время обратного хода луча (где делается гашение) что ли так сказано? Хм.
Может лучше не выдёргивать фразы из контекста? Речь шла про эмуляцию сигналов, а не про реальные сигналы.
Но некоторые термины подправлю в статье.
Уверен, что вы упустили прочесть описание видеосигнала, приходящего на монитор по VGA. :)
уверен что не упустил прочитать описание видеосигнала. При том, что на канале есть ссылки дополнительные, где человек может подсмотреть (читают сейчас, увы, мало) необходимую информацию по VGA-сигналам.
Много букв... Пойду лучше код писать, ведь мой код, обычно, не занимает даже мегабайта. Ну ладно, исходный текст занимает 3+ метра. + либы под разные архитектуры и ОС 10+ метров...
И? Это везде так. И в синтаксисе Intel тоже надо запоминать. Что вы пытаетесь тогда доказать?
Получается, что синтаксис Intel всё равно исходный
Где я писал обратное?
Для чего именно?
Для компилятора.
Я повторяюсь? Я ведь уже это написал?!
Последовательность байтов. Достаточно развернуть последовательность и получим тот же самый код, только из другого синтаксиса (вы точно программист?).
Возможно это мои догадки, но пока тут с вами демагогией занимаюсь, пришло на ум что синтаксис AT&T более правильный по отношению к компилятору. Надо будет изучить этот вопрос и более точно всё узнать. Наверняка не просто так была развёрнута последовательность источников и приёмника.
Какая логика вам объясняет, когда писать cwtl, а когда - cwtd?
Довольно странный вопрос. Вы знаете что делает команда cwtl? cwtd?
Вы не видите различия их конечной работы? Или конечный результат eax против dx:ax ни чего не значит?
Как так получилось, что уменьшаемое справа от вычитаемого?
Да, такие моменты обескураживают. Но видятся достаточно логичными. Если у Intel операнд-приёмник идёт первым, а операнд-источник последним, то при полном развороте (когда два источника, один приёмник) для синтаксиса AT&T будет достаточно правильно поменять местами именно все операнды, а не какой-то один (но это лишь догадки с моей стороны).
Вполне возможно преследовали цель упростить компиляцию текста. Ведь в данном случае надо просто последовательно считать значения один за другим, не меняя в дальнейшем их местами.
Кто занимается тут игрой слов, вопрос спорный, но я попытаюсь перейти к конструктиву.
Проблема в том, что вы выше, уже за меня всё решили. Удобнее это мне или нет.
Но это лишняя затрата умственных сил, порой резко заметная.
Человеку надо тратить умственные силы, чтоб "не засиживаться на месте". Голова человека должна работать и человек должен осознавать свои ошибки и уметь их исправлять.
Так что зачастую, лишний раз пошевелить мозгами не помешает.
Я отвечал на ваш вопрос - "зачем перешли", а не "зачем его использовать", "зачем сохранять" и всё такое.
Тогда не соизволите объяснить, каким образом ваше мнение должно было учитываться при переходе/не переходе с одного синтаксиса на другой? Для разработчиков Unix в то время.
Логики нет у обоих, но у Intel хоть как-то ровнее.
cbtw или cbw - byte to word cwtl или cwde - word to longword cltq или cdqe - longword to qword
В чём ровнее? Для AT&T я даже не задумываюсь о том, какое идёт расширение.
В чём именно ближе?
В том, что стали просто буквы использовать, а не полномасштабные команды. Если следовать логике Intel, то все команды должны быть расписаны чуть ли не в длинную цепочку каждое слово отдельно (это субъективное мнение).
Нет, не нам. Нам лишь решать использовать этот синтаксис или нет.
почему вы думаете
Не надо заниматься игрой слов. Если вам этот синтаксис не удобен, то это не значит что он не удобен другим. Все ваши "недочёты", нивелируются человеком который читает код и понимает разницу между синтаксисом AT&T и Intel.
А люди, которые читают код, иногда даже не обращают внимания на каком ЯП этот код написан. Потому что важна логика кода и что он делает, а не сам код.
Вы решили запретить (нам - кому именно нам?) исследовать историю?
Извиняюсь, что? ))) Зачем в очередной раз играть словами? Если я вам пишу, про то что: "не нам решать, что делать разработчику", но вы решили за разработчика что: "он должен делать так как вы сказали"!
Для меня синтаксис AT&T более удобен. Я к нему быстрее привык, чем к синтаксису Intel. И это при том, что большую часть времени я сидел именно на синтаксисе Intel.
Думаю это не нам решать, по какой причине Unix системы остались на синтаксисе AT&T, а не перешли на соседний.
язык ассемблера x86 имеет две основные синтаксические ветви: Intel syntax и AT & T syntax. Синтаксис Intel доминирует в мире DOS и Windows, а синтаксис AT & T доминирует в мире Unix, поскольку Unix был создан в AT & T Bell Labs.
Допустим кроссплатформенность. Я использую полностью нативный код (конечный компилируемый), а не java-код под разные платформы. Создавая приложение (допустим) под Windows, это приложение практически без переделок можно запустить на Android. Под Linux, MacOS собирается вообще без переделок, понимаем, что для мобильных платформ надо учитывать специфику платформы и взаимодействия с ней.
Многое, собрано до меня. Многие решения сделаны до меня. Какие-то решения сделал лично я. А многие необходимые библиотеки уже готовы к сборке под любую платформу и сделано это теми людьми, кто разрабатывает эти самые библиотеки.
Так что да, какие-то приложения будут дольше разрабатываться из-за того что надо создавать UI и работать с ним, а где-то наоборот, допустим игры. Их проще сделать нативно, ведь там как раз разработка основная не создание UI и работы с ним, а работы самой программы с графикой, при чём UI в данном случае в наименьшем виде. И! Для большинства создаваемых игр UI для игры уже создан. Создавать одно и то же для каждой игры... как-то боком выйдет.
Ну и то же самое с программами, которые активно используют графику, где графический интерфейс нативный, по большей части.
Для понимания, это не опровержение ваших слов! Это просто другая сторона.)))
Но мы отошли от моего вопроса: что из перечисленного в статье поможет мне именно с нативной составляющей программ? )))
Мне нужен java-код только для работы с полностью нативными приложениями. Полностью нативное приложение - это приложение привязанное к данной архитектуре и оно не сможет выполняться на другой архитектуре.
Это не значит, что разработанное мной приложение не будет работать на других архитектурах, это означает, что для каждой архитектуры будет свой нативный код.
Я создаю активити, прописываю необходимые методы и использую данные в нативном коде.
Что из перечисленного позволит мне сделать то же самое?
Удивление?
Не стоит путать "удивление" и "недопонимание". Написан конкретный вопрос в том, что я могу недопонимать, а не в том, в чём я удивлён. В век цифровой аппаратуры, лично я бы передавал сигнал по широкой шине, где передавались бы и координаты и цвет для данной координаты. Это даст возможность вывода с большей частотой больше информации.
Если есть какая-то конкретная информация, то лучше было поделиться ей, чем разводить демагогию.
Может лучше не выдёргивать фразы из контекста? Речь шла про эмуляцию сигналов, а не про реальные сигналы.
Но некоторые термины подправлю в статье.
уверен что не упустил прочитать описание видеосигнала. При том, что на канале есть ссылки дополнительные, где человек может подсмотреть (читают сейчас, увы, мало) необходимую информацию по VGA-сигналам.
Но опять же статью надо будет дополнить... )))
Полезная ссылка! Благодарю!
Много букв...
Пойду лучше код писать, ведь мой код, обычно, не занимает даже мегабайта. Ну ладно, исходный текст занимает 3+ метра. + либы под разные архитектуры и ОС 10+ метров...
Дамп своей игры (купленной) не является пиратством.
Точнее это я сам себе писал?
или мне привиделось?
Ну тогда можно было тогда взять (для примера) кроссплатформенный ассемблер FasmG. Зачем брать для этого ЯВУ?
Нападение лучшее средство защиты. Это ведь я писал:
Цитата: "Эээ... вообще-то и нам, и кому угодно."
в ответ на мои слова, цитата: "Думаю это не нам решать, по какой причине Unix системы остались на синтаксисе AT&T, а не перешли на соседний."
... и опять же скажем что мы ни за кого ни чего не решаем... всё по стандарту...
Думаю пора завязывать этот диалог.
И? Это везде так. И в синтаксисе Intel тоже надо запоминать. Что вы пытаетесь тогда доказать?
Где я писал обратное?
Для компилятора.
Я повторяюсь? Я ведь уже это написал?!
Последовательность байтов. Достаточно развернуть последовательность и получим тот же самый код, только из другого синтаксиса (вы точно программист?).
Возможно это мои догадки, но пока тут с вами демагогией занимаюсь, пришло на ум что синтаксис AT&T более правильный по отношению к компилятору. Надо будет изучить этот вопрос и более точно всё узнать. Наверняка не просто так была развёрнута последовательность источников и приёмника.
Довольно странный вопрос. Вы знаете что делает команда cwtl? cwtd?
Вы не видите различия их конечной работы? Или конечный результат eax против dx:ax ни чего не значит?
Да, такие моменты обескураживают. Но видятся достаточно логичными. Если у Intel операнд-приёмник идёт первым, а операнд-источник последним, то при полном развороте (когда два источника, один приёмник) для синтаксиса AT&T будет достаточно правильно поменять местами именно все операнды, а не какой-то один (но это лишь догадки с моей стороны).
Вполне возможно преследовали цель упростить компиляцию текста. Ведь в данном случае надо просто последовательно считать значения один за другим, не меняя в дальнейшем их местами.
Проблема в том, что вы выше, уже за меня всё решили. Удобнее это мне или нет.
Человеку надо тратить умственные силы, чтоб "не засиживаться на месте". Голова человека должна работать и человек должен осознавать свои ошибки и уметь их исправлять.
Так что зачастую, лишний раз пошевелить мозгами не помешает.
Тогда не соизволите объяснить, каким образом ваше мнение должно было учитываться при переходе/не переходе с одного синтаксиса на другой? Для разработчиков Unix в то время.
cbtw или cbw - byte to wordcwtl или cwde - word to longword
cltq или cdqe - longword to qword
В чём ровнее? Для AT&T я даже не задумываюсь о том, какое идёт расширение.
В том, что стали просто буквы использовать, а не полномасштабные команды. Если следовать логике Intel, то все команды должны быть расписаны чуть ли не в длинную цепочку каждое слово отдельно (это субъективное мнение).
сами придумали команду?
В синтаксисе AT&T специально к командам "прицепили" буквы: b, w, l, q, s, t.
Странно что вы не жалуетесь на формат команд SIMD-инструкций. Ведь это ближе к AT&T синтаксису, а не Intel.
Нет, не нам. Нам лишь решать использовать этот синтаксис или нет.
Не надо заниматься игрой слов. Если вам этот синтаксис не удобен, то это не значит что он не удобен другим. Все ваши "недочёты", нивелируются человеком который читает код и понимает разницу между синтаксисом AT&T и Intel.
А люди, которые читают код, иногда даже не обращают внимания на каком ЯП этот код написан. Потому что важна логика кода и что он делает, а не сам код.
Извиняюсь, что? ))) Зачем в очередной раз играть словами? Если я вам пишу, про то что: "не нам решать, что делать разработчику", но вы решили за разработчика что: "он должен делать так как вы сказали"!
Для меня синтаксис AT&T более удобен. Я к нему быстрее привык, чем к синтаксису Intel. И это при том, что большую часть времени я сидел именно на синтаксисе Intel.
Думаю это не нам решать, по какой причине Unix системы остались на синтаксисе AT&T, а не перешли на соседний.
если вы найдёте на чём тестировать ваш код, то возможно всё что вашей душе угодно.
Это "недоразумение" существовало и использовалось ещё на PDP11.
вырезка из https://en.wikipedia.org/wiki/X86_assembly_language#Syntax (перевод)
Но думаю это стоит расписать в отдельной теме. Здесь же я больше основывался именно на ассемблере.
Есть разные задачи, и они требуют разных решений.
Допустим кроссплатформенность. Я использую полностью нативный код (конечный компилируемый), а не java-код под разные платформы. Создавая приложение (допустим) под Windows, это приложение практически без переделок можно запустить на Android. Под Linux, MacOS собирается вообще без переделок, понимаем, что для мобильных платформ надо учитывать специфику платформы и взаимодействия с ней.
Многое, собрано до меня. Многие решения сделаны до меня. Какие-то решения сделал лично я. А многие необходимые библиотеки уже готовы к сборке под любую платформу и сделано это теми людьми, кто разрабатывает эти самые библиотеки.
Так что да, какие-то приложения будут дольше разрабатываться из-за того что надо создавать UI и работать с ним, а где-то наоборот, допустим игры. Их проще сделать нативно, ведь там как раз разработка основная не создание UI и работы с ним, а работы самой программы с графикой, при чём UI в данном случае в наименьшем виде. И! Для большинства создаваемых игр UI для игры уже создан. Создавать одно и то же для каждой игры... как-то боком выйдет.
Ну и то же самое с программами, которые активно используют графику, где графический интерфейс нативный, по большей части.
Для понимания, это не опровержение ваших слов! Это просто другая сторона.)))
Но мы отошли от моего вопроса: что из перечисленного в статье поможет мне именно с нативной составляющей программ? )))
Я их между собой приравниваю. Да, я не изучал котлин, но не думаю что там что-то сложнее и проще. Просто по другому немного.
На яве пишу, потому что привык и мне много ява-кода не нужно.
Ну... на несколько порядков, это в 10-100-1000 и т.д. раз медленнее.
Почему-то я в этом не уверен. Сейчас вроде не 2000-й год, когда для нативного кода ни каких наработок нет. )))
А так да, медленнее, но в сборке, обычно быстрее.
Ни чем из этого не пользуюсь. Практически ни чем.
Мне нужен java-код только для работы с полностью нативными приложениями. Полностью нативное приложение - это приложение привязанное к данной архитектуре и оно не сможет выполняться на другой архитектуре.
Это не значит, что разработанное мной приложение не будет работать на других архитектурах, это означает, что для каждой архитектуры будет свой нативный код.
Я создаю активити, прописываю необходимые методы и использую данные в нативном коде.
Что из перечисленного позволит мне сделать то же самое?