массивы на ассемблере - Низкоуровневое программирование

Здравствуйте, Кодёнок, Вы писали:

Кё>Это совершенно неправильно и нелогично.

Почему тогода при изучении математики такой подход? Сначала яблоки, потом числа, потом поля.

Кё>Начинать следует с высокого уровня и углубляться в детали постепенно.

Ответ на вопрос "почему?" будет хоть у когото?

Ассемблер не мешает изучать "высокий уровень" (здесь внизу более развернуто)

Кё>Из того факта, что ассемблер более всего способствеует понимаю, как работает компьютер, никак не следует, что с него надо начинать.

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

GN>>BulatZiganshin в школе компелировал в хекскодах, а теперь написал лучший в мире архиватор.

Кё>КомпИлировал. Начинал-то он не с хекс-кодов.

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

Тем не менее:
Re[2]: Как построить карьеру?
Re[7]: истинный смысл технических интервью

А компИлирует компилятор. Кампеляция — это "другой термин" — название процесса, чем-то напоминающий работу автоматических инструментов

Кё>Устал писать на Си и сделал С++. Уж с историей языка-то можно было ознакомиться.

Ознакамливался. К сожалению, мне сложно искать и цитировать бумажную D&E, где Бьёрн пишет, что он не был экспертом по С, а писал на BCPL и Simula (который не устраивал в силу тормозов). Поэтому воспользовался гуглом

C++ was designed primarily so that my friends and I would not have to program in assembler, C, or various modern high-level languages

Совместимости с C лёгла в основу, т.к это промышленный язык. И нужно просто не знать ассемблер PDP, что бы утверждать. что K&R C чем-то от него принципиально отличается, кроме синтакиса.

Кё>Тезис Черча-Тьюринга к механизмам обучения людей никак не относится и не применяется.

Однако он "ставит знак равенства" между языками.

Кстати, уже показательно — 2й человек не может ничего сказать о начале обучения более, чем пытаться отрицать мои аргументы. Зачем же выбирать тупиковый путь: даже если моя теория будет признана неверной, это никак не докажет верность любых других теорий

Здравствуйте, gear nuke, Вы писали:

Кё>>Тезис Черча-Тьюринга к механизмам обучения людей никак не относится и не применяется.

GN>Однако он "ставит знак равенства" между языками.

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

Здравствуйте, gear nuke, Вы писали:

Кё>>Начинать следует с высокого уровня и углубляться в детали постепенно.
GN>Ответ на вопрос "почему?" будет хоть у когото?

Ассемблер не мешает изучать "высокий уровень" (здесь внизу более развернуто)

Потому что принцип обучения — от простого к сложному. Простое — это меньшее количество делатей, которые необходимо изучить перед выполнением задания. Арифметика, последовательности и строки — это уже известно обучающемуся. Чтобы показать, как складывать числа, в его внимание вводится только синтаксис, и пара стандартных функций. Ассемблер заставляет вводить концепт памяти, регистров, адресов, стека, компиляции в конце концов, просто чтобы естественную операцию сделать. Поэтому он хуже.

Кё>>Из того факта, что ассемблер более всего способствеует понимаю, как работает компьютер, никак не следует, что с него надо начинать.
GN>Я не подменяю необходимые и достаточные условия. С него начиать не следует, а можно. Чувствуешь разницу?

Если ставить вопрос как «можно ли», то я скажу что можно и кокосы лбом колоть. Если вопрос стоит — как учиться лучше и быстрее, то ассемблер не лучший выбор.

GN>Ознакамливался.

Либо «знакомился», либо «ознакомился».

GN>Кстати, уже показательно — 2й человек не может ничего сказать о начале обучения более, чем пытаться отрицать мои аргументы. Зачем же выбирать тупиковый путь: даже если моя теория будет признана неверной, это никак не докажет верность любых других теорий

Или просто не хочешь понять, что тебе объясняют.

Здравствуйте, Кодёнок, Вы писали:

Кё>Ассемблер заставляет вводить концепт памяти, регистров, адресов, стека, компиляции в конце концов, просто чтобы естественную операцию сделать. Поэтому он хуже.

Вот это уже — что надо

Спасибо, я понял свою ошибку — подразумевал, что эти знания уже есть у автора топика.

Кё>Или просто не хочешь понять, что тебе объясняют.

Снимаю перед тобой шляпу, если ты увидел объяснения в оспариваниях Сергей Мухин

Здравствуйте, gear nuke, Вы писали:

GN>Спасибо, я понял свою ошибку — подразумевал, что эти знания уже есть у автора топика.

да, лопухнулся, но признать ошибку — большое достоинство, не все так могут.

Кё>>Или просто не хочешь понять, что тебе объясняют.

GN>Снимаю перед тобой шляпу, если ты увидел объяснения в оспариваниях Сергей Мухин

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

Здравствуйте, Сергей Мухин, Вы писали:

СМ>да, лопухнулся, но признать ошибку — большое достоинство, не все так могут.

Верно заметил — ввязаться в спор с людьми, не читавшими п.5 правил, и делающими безосновательные выводы о незнании топикстартером таких вещей как регистры, компиляция, ... — это именно "лопухнуться".

СМ>т.е. я оказался прав, только не смог донести до аудитории. будем работать.

Прав, мантра "ассемблер — наихудьший вариант" действительно есть.

СМ>будем работать.

Первый шаг — ответ на вопрос "почему?" в этом топике.

СМ>>>начинать лучше не с ассемблера. Это наихудший вариант начала.
GN>>Почему это? По-моему, вполне логичен переход к от абстракций низших порядков к высшим.
Кё>Это совершенно неправильно и нелогично. Начинать следует с высокого уровня и углубляться в детали постепенно.
+1 И вообще это по-моему большая беда современного образования. Многим людям свойственнен дедуктивный стиль мышления, он более естественнен для человека и дает много плюсов по сравнению с индуктивным, прививание которого с школьной (универской) скамьи сравнимо с перевоспитанием левшей в правшей.

Здравствуйте, <Аноним>, Вы писали:

А>+1 И вообще это по-моему большая беда современного образования. Многим людям свойственнен дедуктивный стиль мышления, он более естественнен для человека и дает много плюсов по сравнению с индуктивным, прививание которого с школьной (универской) скамьи сравнимо с перевоспитанием левшей в правшей.

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

Вот, кстати, интересное мнение

Why have a machine language?

Many readers are no doubt thinking, ``Why does Knuth replace MIX by another machine instead of just sticking to a high-level programming language? Hardly anybody uses assemblers these days.''

Such people are entitled to their opinions, and they need not bother reading the machine-language parts of my books. But the reasons for machine language that I gave in the preface to Volume 1, written in the early 1960s, remain valid today:

One of the principal goals of my books is to show how high-level constructions are actually implemented in machines, not simply to show how they are applied. I explain coroutine linkage, tree structures, random number generation, high-precision arithmetic, radix conversion, packing of data, combinatorial searching, recursion, etc., from the ground up.

The programs needed in my books are generally so short that their main points can be grasped easily.

People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird.

Machine language is necessary in any case, as output of many of the software programs I describe.

Expressing basic methods like algorithms for sorting and searching in machine language makes it possible to carry out meaningful studies of the effects of cache and RAM size and other hardware characteristics (memory speed, pipelining, multiple issue, lookaside buffers, the size of cache blocks, etc.) when comparing different schemes.

Moreover, if I did use a high-level language, what language should it be? In the 1960s I would probably have chosen Algol W; in the 1970s, I would then have had to rewrite my books using Pascal; in the 1980s, I would surely have changed everything to C; in the 1990s, I would have had to switch to C++ and then probably to Java. In the 2000s, yet another language will no doubt be de rigueur. I cannot afford the time to rewrite my books as languages go in and out of fashion; languages aren't the point of my books, the point is rather what you can do in your favorite language. My books focus on timeless truths.

Therefore I will continue to use English as the high-level language in TAOCP, and I will continue to use a low-level language to indicate how machines actually compute. Readers who only want to see algorithms that are already packaged in a plug-in way, using a trendy language, should buy other people's books.

А>>+1 И вообще это по-моему большая беда современного образования. Многим людям свойственнен дедуктивный стиль мышления, он более естественнен для человека и дает много плюсов по сравнению с индуктивным, прививание которого с школьной (универской) скамьи сравнимо с перевоспитанием левшей в правшей.
GN>Перечислите, пожалуйста, плюсы. Людям с "недедуктивным стилем" сложно понять, что подразумевалось под пропущенным словом "очевидные"
Это значит что когда человек решает проблему, он сперва видит проблему и анализирует ее общие черты. Затем постепенно углубляется в суть проблемы. Это естественный путь познания. А в современной системе образования приучают к другому пути — встретивись с системой которую надо изучить, разбить ее на множество возможно более мелких подсистем, изучить каждую из них и затем изучить подсистемы которые они составляют и далее по восходящей. Такой подход позволяет быстро и типово изучать сравнительно небольшие системы (решать несложные проблемы), но при столкновении с реально большой системой он требует ее досконального изучения, прежде чем станет ясен тот самый кусок который вас изначально интересовал.
Говоря языком программеров:
Индуктивный подход требует при каком либо некорректном поведении софта садиться за дебаггер и постепенно изучать строку за строкой прежде чем разобраться что какую роль играют конкретные строки, классы, модули etc в баге которую требуется пофиксить.
Дедуктивный предполагает изучение проблемного функционала сверху вниз, вначале нахождение ответственных логических путей в общей архитектуре, потом модули, потом классы и логические связи основываясь на анализе исходников и логов.. И потом если сразу станет неясно легкий дебаг. Для реально больших систем которые нужно быстро исправлять минимально затрагивая остальную архитектуру так обычно эффективнее.

Говоря языком программеров, вы сами-то, когда новый язык изучали, как поступали:

1. Читали reference, где объясняются синтаксические конструкции (в виде EBNF) и их семантика, затем, узнав все кирпичики, отобрали нужные и составили свою первую программу?

2. Или же, скопировали пример из getting started, запустили его (ничего не меняя), затем начали менять числа, добавлять вызовы и т.д., заглядывая в reference и читая только нужное исключительно только тогда, когда что-то не получается?

Кё>Говоря языком программеров, вы сами-то, когда новый язык изучали, как поступали:
Кё>1. Читали reference, где объясняются синтаксические конструкции (в виде EBNF) и их семантика, затем, узнав все кирпичики, отобрали нужные и составили свою первую программу?
Кё>2. Или же, скопировали пример из getting started, запустили его (ничего не меняя), затем начали менять числа, добавлять вызовы и т.д., заглядывая в reference и читая только нужное исключительно только тогда, когда что-то не получается?

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

Здравствуйте, ononim, Вы писали:

А>>>прививание которого с школьной (универской) скамьи

После прочтения ответа только дошло. Хотя ясно написано прямым текстом

Школа и университет — это вообще-то разные системы и учат там разным вещам и по-разному. Даже названия — начальная, средняя, высшая.. И яблоки учат считать, и теоремы доказывать индукцией, и ТРИЗ... И именно в таком порядок не спроста — без базовых знаний, что дерево горит, нельзя "изобрести из спички зубочистку", кроме как методом проб и ошибок (не путать с методом Тыка).

Поэтому мне и неясно, почему изучение программирования надо начинать не с битов... В чём выгода дедуктивного подхода для общего случая, когда решаемая проблема вообще "неизвестна"

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

Re[5]: массивы на ассемблере — был хороший ответ. Пока у обучающегося не возникнут вопросы "а что же такое переменная на самом деле", или "почему моя старая прога на Perl рвёт написанную после прочтения С++ за 2 дня свежую версию.

А>>>сравнимо с перевоспитанием левшей в правшей.

Подавление врождённых способностей — первый признак дилетанства учителя. Но в школе готовят не Мастеров, а роботов, там подход "экономически оправдан". Я ожидал здесь несколько большего, против ответа "для кого-то, асм — наихудший вариант начала" не возражал бы.

O>Это значит что когда человек решает проблему, он сперва видит проблему и анализирует ее общие черты. Затем постепенно углубляется в суть проблемы. Это естественный путь познания. А в современной системе образования приучают к другому пути — встретивись с системой которую надо изучить, разбить ее на множество возможно более мелких подсистем, изучить каждую из них и затем изучить подсистемы которые они составляют и далее по восходящей. Такой подход позволяет быстро и типово изучать сравнительно небольшие системы (решать несложные проблемы), но при столкновении с реально большой системой он требует ее досконального изучения, прежде чем станет ясен тот самый кусок который вас изначально интересовал.

Гм. Как раз

есть такие две (противоположные) модели разработки — Waterfall и Reverse Engineering. Вот первая как раз и способна решать только несложные проблемы — поскольку не всегда можно увидеть правильно даже проблему в целом, не говоря о более мелких деталях. Так что выходит, учат правильно.

Другое дело, что знания нужно еще правильно применить. RE (например, самый примитивный — Bit-Hack) не требует досконального изучения системы, кроме случая, когда именно изучение является целью. Правильный RE требует применять прямое проектирование, где можно

— это находит отражение и в альтернативных моделях — где нужно, применять обратное

O>Говоря языком программеров:

O>Индуктивный подход требует при каком либо некорректном поведении софта садиться за дебаггер и постепенно изучать строку за строкой прежде чем разобраться что какую роль играют конкретные строки, классы, модули etc в баге которую требуется пофиксить.

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

O>Дедуктивный предполагает изучение проблемного функционала сверху вниз, вначале нахождение ответственных логических путей в общей архитектуре, потом модули, потом классы и логические связи основываясь на анализе исходников и логов.. И потом если сразу станет неясно легкий дебаг. Для реально больших систем которые нужно быстро исправлять минимально затрагивая остальную архитектуру так обычно эффективнее.

О, да это не ошибки даже

Если надо лезть "вверх" функционала — это значит, что софт работает именно так, как сказали ему разработчики. Но они либо сказали плохо, либо вообще представляли проблему не полно. Waterfall, одним словом

Здравствуйте, Сергей Мухин, Вы писали:

СМ>начинать лучше не с ассемблера. Это наихудший вариант начала.
Соглашусь с gear nuke, что бездоказательные утверждения имеют нулевой вес. Только вот доказательств чувствую не будет, поскольку их просто нет

СМ>где абстракции, а где ассемблер? Это абсолютные антиподы.
Хм, так говорят все, кто не разбирается в современных ассемблерах, вернее может и знают мнемоники команд, но саму среду разработки — нет

Не буду распинаться об ООП, высокоуровневых конструкциях циклов и условных переходов. Все это поддерживает даже старичок tasm. Но о макросах просто не могу не упомянуть. Это по сути отдельный и довольно мощный язык, причем легко расширяемый. И они позволяют создавать код на более высоком уровне абстракции, нежели многим кажется. Их возможности не ограничиваются созданием высокоуровневых конструкций (if, repeat и тд.). С помощью макросов можно создать даже новый язык, введя любые конструкции. Я реализовывал Форт, ничем не отличающийся от "настоящего" компилятора Форта, разве что в начале каждой строки стоял спецсимвол (для парсинга остальной части). Но можно создать и более высокоуровневые возможности, было бы желание и фантазия.

Впрочем, асм хорош еще и тем, что приучает находить несколько решений и выбирать наиболее подходящее. И именно поэтому он и подходит для начинающих, прививая им эти полезные навыки. За примером не буду далеко ходить, возьмем сабж.
Типичное решение:

array db 256 dup(?)

А можно так:

  array label byte
  rept 256
    db ?
  endm

Или так:

  array label byte
  I = 1
  while I le 256
    db ((I*2) shl 1) and 0ffh
    I = I + 1
  endm

Или даже так:

  array label byte
  org $+256

Можно немного и модернизировать:

  array   label byte
  array_w label word
  array_d label dword
  I = $
  org $+256
  num_elem_b = $-array
  num_elem_w = ($-array) shr 1
  num_elem_d = ($-array) shr 2

А если подумать:

SetArray macro n: req, len: req
  &n& label byte
  &n&_w label word
  &n&_d label dword
% org $+len
  num_elem_&n&_b = $-&n
  num_elem_&n&_w = ($-&n) shr 1
  num_elem_&n&_d = ($-&n) shr 2
endm

data segment
  SetArray array, 256

Могу еще кучу вариантов привести, но для примера вполне хватит и этих. В общем выбор огромный, что и приучает тщательно взвешивать решения, поскольку возможности к откату, если решение окажется неудачным, нередко довольно ограничены. Этого очень не хватает в ЯВУ, где почти все насильно навязывается по заранее подготовленным шаблонам, превращая человека в "собачку Павлова".

Здравствуйте, AndNot, Вы писали:

СМ>>начинать лучше не с ассемблера. Это наихудший вариант начала.
AN>Соглашусь с gear nuke, что бездоказательные утверждения имеют нулевой вес. Только вот доказательств чувствую не будет, поскольку их просто нет

помоему ответ был дан г. Кодёнок здесь

Здравствуйте, AndNot, Вы писали:

AN>Впрочем, асм хорош еще и тем, что приучает находить несколько решений и выбирать наиболее подходящее. И именно поэтому он и подходит для начинающих, прививая им эти полезные навыки.

Это если только ты не ошибся в том, что это именно он тебе её привил. Если ошибся — то не подходит.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>помоему ответ был дан г. Кодёнок здесь

Ну так это не тянет на полноценный ответ, одни лишь утверждения, без доказательств

Любой язык без исключения требует некоторых предварительных знаний и пояснений. И ни в одном не получится: "чтобы показать, как складывать числа, в его внимание вводится только синтаксис, и пара стандартных функций.", сначала придется выучить море правил и ограничений, связанных с идеологией языка, его конструкциями и особенностями. Возьмем "пару стандартных функций". В Сях сначала придется долго и подробно объяснять, откуда взять эти функции (инклюды и либы), полностью объяснить синтаксис, особенности написания программ (например функция main). Только после этого можно переходить к простым примерам. То же самое происходит и с ассемблером, только у него начинать принято с концепции памяти (а регистры — это тоже память), но вполне можно обойтись без инклюдов и либ (для начала). Ведь и асму можно обучать довольно быстро, по принципу Си, когда "вводится только синтаксис, и пара стандартных функций":

ideal
P386
model flat, stdcall

extrn   printf                  : PROC

macro _printf frm: req, par: rest
  local s
dataseg
  s db frm,0
codeseg
    ifnb <par>
        call    printf C, offset s, par
    else
        call    printf C, offset s
    endif
endm

CODESEG
    Start:
        _printf <"Hello World!",13,10>
        ret
END Start

А что, пример смотрится ничуть не сложнее, нежели на Сях и знаний для него нужно не так уж и много. Только вот такой подход чреват тем, что вместо Программиста вырастит Обезьяна, наученная лишь пользоваться WinApi (взамен сишному RTL). Это надо? Нет конечно. Поэтому для изучения любого языка необходимо вначале освоить множество особенностей. Повторяю — для любого. И в этом отношении асм ничуть не хуже других языков. А отсутствие в нем строгой типизации данных, размытости между кодом и данными, и приводит к многообразию различных решений почти любой задачи, заставляя включать соображалку. Да и на асме как то лучше усваиваются особенности двоичной арифметики.

Здравствуйте, AndNot, Вы писали:

спасибо за пример. показать ублюдочность ассемблера, достаточно вызвать сишный принт!

а кто будет рассказывать, как подключать библиотеки от С?. Правила передачи параметров и тп.

Здравствуйте, Сергей Мухин, Вы писали:

СМ>спасибо за пример. показать ублюдочность ассемблера, достаточно вызвать сишный принт!

Устаревший термин «ублюдок» в биологии в настоящее время полностью вытеснен словом «гибрид»

Суть языка подмечена верно, а вложенные эмоции отлично объясняют Re: массивы на ассемблере и показывают, что оно очень субъективно.

Очень похоже на тороллирование.

СМ>а кто будет рассказывать, как подключать библиотеки от С?. Правила передачи параметров и тп.

Замечательная тактика — не отвечая, спрашивать, причём без смысла — в случае с С всё это тоже надо рассказывать.

Здравствуйте, gear nuke, Вы писали:

GN> и показывают, что оно очень субъективно.

объективно — количество проектов на ассемблере и на С/С++ или других языках? есть такая статистика? и лучше по годам.

GN> Очень похоже на тороллирование.

это что такое? google сказал: Возможно, вы имели в виду: паролирование

СМ>>а кто будет рассказывать, как подключать библиотеки от С?. Правила передачи параметров и тп.

GN>Замечательная тактика — не отвечая, спрашивать, причём без смысла — в случае с С всё это тоже надо рассказывать.

слева направо или как? снимается со стека или как? сколько байтов передается double? а структура? в С совершенно не обязательно.

Здравствуйте, AndNot, Вы писали:

AN>Ну так это не тянет на полноценный ответ, одни лишь утверждения, без доказательств

Доказательства находятся в тебе. Если ты наблюдал за собой во время обучения, как оно происходит, то доказательств не нужно — ты видел факты. Если нет, то тебе этого никак не показать. Чтобы стать хорошим програмистом, ты потратил годы, но чтобы разобраться, как происходит обучение, ты явно потратил максимум 5 минут. Зато авторитетные суждения, что лучше, а что хуже, уже делаешь.

AN>Любой язык без исключения требует некоторых предварительных знаний и пояснений. И ни в одном не получится: "чтобы показать, как складывать числа, в его внимание вводится только синтаксис, и пара стандартных функций.", сначала придется выучить море правил и ограничений, связанных с идеологией языка, его конструкциями и особенностями.

Да, я в курсе, что процентов 90% программистов считает, что сначала надо объяснить все кирпичики, и только затем показывать, как из них складывать программу. Это не работает и это наихудший способ обучения. Если б ты попробовал его хоть раз, знал бы.

А еще процентов 90% программистов имеет небольшие трудности с тем, чотбы делать понятные простым людям интерфейсы, понятные простым людям сайты, понятные простым людям объяснения. Странное совпадение.

AN>Возьмем "пару стандартных функций". В Сях сначала придется долго и подробно объяснять, откуда взять эти функции (инклюды и либы), полностью объяснить синтаксис, особенности написания программ (например функция main).

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

AN>CODESEG
AN> Start:
AN> _printf <"Hello World!",13,10>
AN> ret
AN>END Start
AN>А что, пример смотрится ничуть не сложнее, нежели на Сях и знаний для него нужно не так уж и много.

Это не тоже самое, что программа на Си main(){printf("Hello, World!\n");}. Отношение нужных понятий к ненужным просто удручающее. И сравни с программой на Питоне:

print "Hello, World!"

Сколько времени придется потратить на ответы на вопросы «а это что за штука?» от обучаемого в том и в другом случае?

	От:	gear nuke
	Дата:	30.09.08 07:53
	Оценка:

	От:	Сергей Мухин
	Дата:	30.09.08 08:09
	Оценка:

	От:	Кодёнок
	Дата:	30.09.08 08:25
	Оценка:	10 (1) +1

	От:	gear nuke
	Дата:	30.09.08 08:53
	Оценка:

	От:	Сергей Мухин
	Дата:	30.09.08 09:13
	Оценка:

	От:	AndNot
	Дата:	15.10.08 08:13
	Оценка:	10 (1) +2 -1

	От:	Аноним
	Дата:	06.10.08 08:30
	Оценка:

	От:	ononim
	Дата:	08.10.08 16:21
	Оценка:

	От:	Аноним
	Дата:	09.10.08 07:20
	Оценка: