.data?
array db 256 dup (?)

GN>>.data?
GN>>array db 256 dup (?)
GN>>

.code
start:
    mov eax, offset array ; загружаем адрес первого элемента в регистр
@@: mov [eax], al         ; наш массив выровнен по границе 4К, поэтому младшей байт адреса равен номеру, сохраним его
    inc al                ; перейдём к следующему элементу
    jnz @b                ; продолжаем цикл пока нет выхода за пределы массива.
end start

пора наконец понять, что интересы вузов в России не совпадают с интересами бизнеса. вузы — это порфессура со знаниями времён царя Гороха, заинтересованная в том, чтобы не осваивая ничего нового, с умным видом продолжать зачитывать свой хлам студентам и на выходе из вуза, когда до них вдруг доходит, что им читали туфту, разводить руками со слвоами "зато мы научили вас учиться". доходы вуза и его отдельных преподавателей НЕ ЗАВИСЯТ от востребованности его выпускников в экономике

представьте себе ассемблер с ООП расширениями, шаблонами, клозурами, монадами, примитивами синхронизации и т.д. смешно? было бы смешно, если б не было близко к правде.

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

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.

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

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

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

printf("Hello World!\n");

GN>Я пробовал, так что должно быть понятно, почему мне сложно признать это самым неэффективным путём Есть другой пример — учил однокласника спектрумному ассемблеру, позже, участь в универе он написал сначала симулятор для обучения студентов, потом еще какую-то систему учета фанарей на улицах. Специальность к CS отношения не имела, он просто взял книжку по Дельфи и читал... интересны были его коммантарии вроде "да и так кое-что уже знаю, вот то в Дельфи делается так-то, а для этого сразу готовая функия", "вот уроды, из-за того-то ГУЙ мерцает, но я сделал вот эдак!". Нет смысла судить, насколько там всё архитектурно правильно было — оба проекта успешны (коммерчески) и ему закрыли кучу сессий автоматом

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