|
Задача написать оптимальный алгоритм преобразования частоты | ☑ | ||
---|---|---|---|---|
0
D_Pavel
10.08.15
✎
06:22
|
Есть какой-то процессор, например 8086. На входе в порт процессора поступают импульсы с какой-то частотой.
Нужно написать оптимальную самое главное по времени расчета, а так же не большую по размеру программу измерения этой частоты, и выдачи из другого порта другой частоты, равной входной частоте помноженной на N, где N - любое число от 0 до 100. Например: N=40.5 На входе 100 Гц На выходе должно быть 4050 Гц. Операцию деления или умножения не предлагать, разумеется. |
|||
1
kosts
10.08.15
✎
06:32
|
(0) На 1С надо написать?
|
|||
2
SeraFim
10.08.15
✎
06:33
|
N - целое число?))
А циклом суммировать можно?) |
|||
3
D_Pavel
10.08.15
✎
06:37
|
(1) Хоть на чем, что можно потом скомпилировать в машинные коды.
(2) Не целое. Можно хоть циклом, если это будет оптимально. |
|||
4
Xapac
10.08.15
✎
06:47
|
Функция преобразовательчастоты(N, H)
возврат N*H; КонецФункции; оно? |
|||
5
Маратыч
10.08.15
✎
06:54
|
(0) Помнится, игрался с умножением сдвигом, есть на просторах Сети даже софтинка, рассчитывающая оптимальный алгоритм умножения сдвигом на константу. Но там, во-первых, работа с целочисленной константой, во-вторых, если констант несколько (100 штук, ага), для каждой нужно свой алгоритм в код вкорячивать.
|
|||
6
ДенисЧ
10.08.15
✎
06:54
|
(0) если нужно - напиши. В чем проблема?
|
|||
7
Lama12
10.08.15
✎
06:56
|
(0) Почему умножение не предлагать? Я не помню есть ли в ассемблере умножение, но предполагаю что в современных процессорах что-то осталось от мотсопроцессоров 90х годов :)
|
|||
8
ЧеловекДуши
10.08.15
✎
06:58
|
(0) Какова формула расчета? Что за сложность?
И в чем оптимальность? Каждый язык программирования требует собственную оптимальность :) ... Чет автор темнит, иль выполнить на Ассемблере простое умножение уже не может? :) |
|||
9
ЧеловекДуши
10.08.15
✎
06:59
|
(7) На Ассемблере есть все, ведь по сути это самый нижний уровень... ниже только бит-ы :)
|
|||
10
D_Pavel
10.08.15
✎
07:15
|
(4) Оно, только у тебя не вычислено "H" и не понятно что делать с результатом функции.
|
|||
11
D_Pavel
10.08.15
✎
07:16
|
(6) Написал уже. Интересно сможет ли кто-нибудь такой же хитрый маневр придумать, или даже еще лучше.
|
|||
12
D_Pavel
10.08.15
✎
07:18
|
(7) Потому что вариант с умножением сильно отстает по скорости от множества других более оптимальных вариантов решения этой задачи.
|
|||
13
1Сергей
10.08.15
✎
07:22
|
теперь самый главный вопрос. как запустить 8.3 на 8086?
|
|||
14
D_Pavel
10.08.15
✎
07:23
|
(13) Отличный вопрос. Жаль что он не имеет отношения к данной теме, а то бы обсудили его.
|
|||
15
Feunoir
10.08.15
✎
07:26
|
(12) Да ну? Ещё 486 процессор на своём сопроцессоре умножал вещественные числа одинарной точности за 11 тактов. А уж современные процессоры это вообще за пару тактов делают. Ну попробуй, напиши что-то более быстрое.
|
|||
16
1Сергей
10.08.15
✎
07:27
|
(15) >>А уж современные процессоры это вообще за пару тактов делают.
можно с этого место поподробнее |
|||
17
ЧеловекДуши
10.08.15
✎
07:27
|
Держи, Оптимизация программ на ассемблере, как раз под 8086
http://www.codenet.ru/progr/optimize/asm_opt2.php |
|||
18
D_Pavel
10.08.15
✎
07:28
|
(15) Сопроцессора в условии задачи не было.
|
|||
19
D_Pavel
10.08.15
✎
07:30
|
(5) Молодец, Маратыч, понял суть основной проблемы этой задачи.
|
|||
20
Feunoir
10.08.15
✎
07:33
|
(16) http://www.maxwolf.ru/faq/cpu/fpuclks.html
(18) Ну найди процессор без сопроцессора, я на него гляну, ага. Начиная с 486 это неотъемлемая (за исключением 486SX) часть основного процессора. |
|||
21
rphosts
10.08.15
✎
07:37
|
(0) тупо считаешь кол-во тактов между 2 импульсами на входе(пусть T1). Делишь на свой множитель (Т1/N)... всё, больше входной сигнал не нужен, каждые Т1/N тактов процессора выплёвывать на выход импульс.
|
|||
22
D_Pavel
10.08.15
✎
07:40
|
(21) Ну правильно. Только Т1/N довольно медленная и не оптимальная операция. Нужно что-то более быстрое.
|
|||
23
D_Pavel
10.08.15
✎
07:41
|
(20) 8086 например.
|
|||
24
Маратыч
10.08.15
✎
07:41
|
(22) Самое быстрое - зашить в код предварительно рассчитанные результаты всех возможных перемножений %))
Только про оптимальный размер можно забыть. |
|||
25
rphosts
10.08.15
✎
07:42
|
(22) ну типа она выполняется только 1 раз за всё время. Потом на числа с плавающей точкой просто так не делится...
|
|||
26
Маратыч
10.08.15
✎
07:43
|
(15) Ты не поверишь, до появления MMX-ов до 130 тактов доходило. Именно умножение.
|
|||
27
D_Pavel
10.08.15
✎
07:44
|
(24) Это точно. Проблема в том что множители могут быть как однобайтовые, так и двух-трех байтовые, да и N не целое число, слишком много вариантов получается. Не годится.
|
|||
28
Feunoir
10.08.15
✎
07:46
|
(26) Я не просто верю, я знаю. Впрочем если у ТС чисто академический интерес, то можно и помучиться.
|
|||
29
D_Pavel
10.08.15
✎
07:46
|
(25) Цель - вычислять как можно быстрее. Потому что это не один раз вычисляется, а много раз, так как частота может изменяться. Время вычисления должно укладываться в один период импульса.
|
|||
30
Lama12
10.08.15
✎
08:48
|
(0)F можно граничные условия озвучить? Какова максимальная частота на выходе может быть?
|
|||
31
Lama12
10.08.15
✎
08:48
|
F=А
|
|||
32
D_Pavel
10.08.15
✎
08:55
|
(30) Максимальная частота не ограничена, все упирается в алгоритм. Чем лучше алгоритм, тем более высокую частоту сможет обработать процессор, либо более медленный процессор будет возможно использовать.
|
|||
33
kudlach
10.08.15
✎
09:08
|
(29) Если на выходе частота должна превышать частоту на входе и частота на входе сравнима с частотой процессора, тады ой.... Озвучивай порядок частот.
|
|||
34
Lama12
10.08.15
✎
09:16
|
(32) Не хочется огорчать, но теорема Котельникова говорит что выше чем половина частоты процессора. на выходе не получишь. При условии что лучшие компиляторы дают замедление производительности примерно в 3 раза (по сравнению с аппаратной реализацией), а в среднем 5-10 раз, то при использовании процессора с частотой 3 ГГц, на выходе получишь максимум 500 кГц. Для более высоких частот нужна аппаратная реализация. Стоит ли заморачиваться на оптимизации кода?
|
|||
35
ДенисЧ
10.08.15
✎
09:18
|
(34) теорема Котельникова про процессоры вообще ничего не говорит...
|
|||
36
Lama12
10.08.15
✎
09:20
|
(35) Да ладно? Какая должна быть частота обработки сигнала определенной частоты, что б его можно было восстановить однозначно?
|
|||
37
ДенисЧ
10.08.15
✎
09:21
|
(36) Я могу тебе на счётах или на бумажке оцифровывать сигнал.
Процессор тут ни причём. И кстати, не частота обработки, а частота дискретизации. |
|||
38
Lama12
10.08.15
✎
09:29
|
(37) Про обработку - утрирую.
Возможно я не туда применил теорему. Тут, вероятно, более верно будет применить ее в к входящему сигналу. Т.е. для вычисления частоты входящего сигнала нужно иметь частоту устройства производящего дискретизацию, примерно в 2 раза выше входящего сигнала. Так наверно буде правильнее. |
|||
39
Mikeware
10.08.15
✎
09:32
|
(34) вы совсем забыли теорему Котельникова...
|
|||
40
D_Pavel
10.08.15
✎
09:33
|
Частота сигнала ограничена только скоростью обработки. То есть если имеем процессор с частотой Х ГГц, то чем лучше напишем программу, тем выше частоту на входе и выходе сможем обработать.
|
|||
41
Lama12
10.08.15
✎
09:37
|
(39)
Хорошо. Какова должна быть частота процессора, что б "воспринять" сигнал частотой 2 ГГц, да так, что бы в последствии его можно было однозначно восстановить? |
|||
42
Остап Сулейманович
10.08.15
✎
09:37
|
(40) Аппаратный умножитель всегда сможет выдать частоту кратную опорной.
|
|||
43
Маратыч
10.08.15
✎
09:41
|
(42) А аппаратные умножители с переменной кратностью бывают? Еще и с дробной к тому же.
|
|||
44
Остап Сулейманович
10.08.15
✎
09:41
|
(41) Зависит от аппаратной реализации счетчика. Если достаточно прочитать количество прошедших импульсов раз в секунду - примерно 3 Гц.
На первом такте получить показания счетчика. На втором умножить на множитель. На третьем выставить множитель на исходящей стороне. |
|||
45
Остап Сулейманович
10.08.15
✎
09:42
|
(43) АВМ может все и даже больше.
|
|||
46
Остап Сулейманович
10.08.15
✎
09:43
|
+ (45) Банальный колебательный контур с переменной емкостью (как на старых приемниках).
|
|||
47
Mikeware
10.08.15
✎
09:43
|
(40) во-первых, выше внутрнней частоты процессора ьы ничего не вычислить, а выше тактовой частоты периферии - не выдашь.
Во-вторых, в задаче не указано, что делать с формой сигнала. В третьих- не сказано про переходные процессы. В четвёртых, такая задача достаточно просто решается периферией МК - скажем, двумя таймерами. Ну а умножить на 10 сдвигами - не вопрос... |
|||
48
Lama12
10.08.15
✎
09:43
|
(44) В том то и дело, что как ни крути, упираемся в аппаратную реализацию АЦП и ЦАП.
|
|||
49
Маратыч
10.08.15
✎
09:44
|
(46) Не, я неверно выразился. Оно в форм-факторе микроконтроллера серийно выпускается?
|
|||
50
D_Pavel
10.08.15
✎
09:44
|
(42) Отлично. А какой алгоритм у аппаратного умножителя?
|
|||
51
Lama12
10.08.15
✎
09:44
|
(45) Кстати - да. АВМ лучший вариант в данном случае.
|
|||
52
D_Pavel
10.08.15
✎
09:46
|
(47) Ну есть у тебя два таймера. Как для них задашь параметры? Их нужно вычислить. В том и вопрос!
|
|||
53
Остап Сулейманович
10.08.15
✎
09:47
|
(49) + (50) http://digteh.ru/digital/MulFr.php
"Данный умножитель частоты допускает только шестнадцать ступеней регулировки тактовой частоты. Код, определяющий коэффициент умножения вводится через упрощенный последовательный порт, собранный на сдвиговом регистре D2. В более сложных схемах умножителей частоты вводятся делители между опорным генератором и фазовым компаратором. Это позволяет реализовывать дробные коэффициенты умножения частоты." |
|||
54
kudlach
10.08.15
✎
09:47
|
(44)Тогда уж, в этой задаче лучше вообще забыть о программировании и вернуться к старым добрым аналоговым аппаратным средствам. Радиотехника ж.
|
|||
55
Mikeware
10.08.15
✎
09:48
|
(46) завязывайте с наркотиками!,©
|
|||
56
D_Pavel
10.08.15
✎
09:48
|
(45) Где же взять этот АВМ, подходящий для задачи?
|
|||
57
Маратыч
10.08.15
✎
09:49
|
(53) О как, а я и не знал.
Тады да, лучший вариант - аппаратная реализация. |
|||
58
D_Pavel
10.08.15
✎
09:50
|
Аналоговые умножители как-то не супер. Нелинейность зависимости входной и выходной частоты присутствует. Цифровой точнее будет.
|
|||
59
Маратыч
10.08.15
✎
09:54
|
(58) Эмм... вот тут, думаю, ты ошибаешься :)
|
|||
60
Mikeware
10.08.15
✎
09:56
|
(54) зачем? STM32 вполне достаточно, даже F0. Эта задача даже не повод рассматривать "взрослые" DSP.
|
|||
61
D_Pavel
10.08.15
✎
09:59
|
(60) Слишком сложно. Давайте ограничимся PIC 12F629 и условиями из (0).
|
|||
62
D_Pavel
10.08.15
✎
10:00
|
+ (61) В нем даже два уже таймера есть, как ты и писал в (47)
|
|||
63
Mikeware
10.08.15
✎
10:19
|
(62) ну и в чем тогда проблема? Первый таймер в захват, все, что он насчитал - делишь на 10, и в регистр второго... Режимы пиков, правда, я плохо помню- но вроде оба нужных есть...
|
|||
64
Mikeware
10.08.15
✎
10:23
|
На СТМке можно проще - тактируешь выходной счётчик в 10 раз более высокой частотой, чем входной, и просто перебрасываешь в прерывании рассчитанное первым счетчиком
|
|||
65
Garykom
гуру
10.08.15
✎
10:27
|
Это только мне кажется что задача в (0) слегка странная и чисто на проце без "бесконечной памяти" не решается?
В общем случае? ЗЫ пришло 1 лям импульсов с частотой 1 Гц, нужно на выход с N = 100, итого выдавать импульсы будем в 100 раз дольше ЗЫ если промежутки между импульсами (частота плавает) разные, то нужен буфер и нехилый |
|||
66
D_Pavel
10.08.15
✎
10:45
|
(63) >> ну и в чем тогда проблема?
Во тв этом: >> что он насчитал - делишь на 10 Делить на 10 долго. Например, мне нужно на каждые 3 входящих такта выдать 2 исходящих. То есть в данном случае N = 0.6667 приблизительно. Долговато деление произойдет. |
|||
67
D_Pavel
10.08.15
✎
10:47
|
(64) >> тактируешь выходной счётчик в 10 раз более высокой частотой
Это не проще. Откуда взять тактовый сигнал? А если не в 10, а в изменяющееся со временем число раз? |
|||
68
Гёдза
10.08.15
✎
10:48
|
Делай что-то типа такого: сдвиг + сложение
https://ru.wikipedia.org/wiki/Снижение_стоимости_операций |
|||
69
Mikeware
10.08.15
✎
10:49
|
Хм. Чойто я в коэффициент 10 впёрся. В условиях- то любой до 100. Ну вот этот коэффициент и загонять в предделитель.
А вообще, задача и правда дурная. |
|||
70
D_Pavel
10.08.15
✎
10:50
|
(69) Аппаратный предделитель там только 2, 4, 8. Не катит.
|
|||
71
Mikeware
10.08.15
✎
10:57
|
(66) делить на 10 - совсем недолго. 3 сдвига, запись, 2 сдвигаа, вычитание. Для пика -вроде циклов 15. Что касается "за такт"- возьми контроллер с подходящей тактовой...
|
|||
72
D_Pavel
10.08.15
✎
11:00
|
(71) Делитель заранее не известен, иначе бы легко было.
|
|||
73
Mikeware
10.08.15
✎
11:01
|
(70) ну и выкинь это .овно, и возьми нормальный. Не нравится - считай на счетах, тактируй кнопкой.
Есть 100500+ способов, но тебе почему-то нужен самый извращенный. |
|||
74
Mikeware
10.08.15
✎
11:16
|
(72) сделай на FPGA. Пример тебе привели выше.
Можешь хоть на кипарисовом соке. |
|||
75
D_Pavel
10.08.15
✎
12:53
|
Сделал частный случай для N = 0.6667
Процедура 9 байт, время обработки одного импульса от 6 до 10 тактов. |
|||
76
D_Pavel
10.08.15
✎
13:11
|
Алгоритм такой:
Прерывание сработает либо при входящем скачке снизу вверх, либо сверху вниз. В обработчике прерывания от входящего сигнала: 1. Инвертирую выход через XOR 2. Если выходной сигнал низкого уровня, тогда возврат из прерывания. 3. Инвертирую через XOR значение уровня входного сигнала, при котором сработает прерывание 4. возврат из прерывания. Всего четыре действия! Но на ассемблере эти четыре действия распухают аж до 9 команд, все таки более низкий уровень. |
|||
77
Rebelx
10.08.15
✎
13:21
|
(0) определись, какая нужна точность.
Если количество значащих цифр укладывается в разрядность процессора - умножай целочисленно на 10Е?? и дели опять же целочисленно на нужный коэффициент. |
|||
78
D_Pavel
10.08.15
✎
13:25
|
(77) По условию задачи нужно ведь оптимальный по скорости алгоритм, а не любой первый попавшийся.
|
|||
79
Rebelx
10.08.15
✎
13:34
|
(78) сколько тактов занимает целочисленное деление и умножение для твоего процессора?
|
|||
80
Rebelx
10.08.15
✎
13:38
|
(78) опять же есть например целочисленные алгоритмы применяемые в машинной графике. В данной задаче наверняка подойтет тот, что рисует прямую - по формуле х = к * у
|
|||
81
D_Pavel
10.08.15
✎
13:42
|
(79) Слишком много, не годится.
(80) аналогично, слишком долго. |
|||
82
Rebelx
10.08.15
✎
13:44
|
(81) слишком много (79) - это сколько?
|
|||
83
D_Pavel
10.08.15
✎
13:55
|
(82) больше чем другими способами можно сделать.
|
|||
84
Кирпич
10.08.15
✎
13:55
|
(81) ты сначала сделай хотя бы медленно, чтобы понять что ты вообще делаешь, а потом уже думай как оптимизировать. а то вакуумного коня тут в ступе толчешь.
|
|||
85
Xapac
10.08.15
✎
14:12
|
(10) ты же написал, что Герцы (H) оно дано на входе.
а что делать с результатом, отправлять его на выход. (ваш КЭП) а где он этот выход. ты уж подробно расскажи задачу. |
|||
86
Кирпич
10.08.15
✎
14:20
|
(85) деление и умножение это вообще не проблема. проблема как выводить эти самые умноженные импульсы. да еще и одновременно со считыванием из другого порта :)
|
|||
87
vde69
10.08.15
✎
14:35
|
Все не читал, на8086 оптимальным будет перехват прерывания таймера, то есть банально нужно изменять максимум счетчика, а генерация бкдет идти автоматом.
только нужно иметь в виду, что на старых ОС нельзя изменять порт часов это грозит разрушением диска, точнее менять можнл, но нужно запрещать дисковые лперации |
|||
88
Kvant1C
10.08.15
✎
14:50
|
(0) А для чего это нужно, если не секрет?
|
|||
89
SUA
10.08.15
✎
14:58
|
умножение еще не предлагали?
тем более с фиксированными константами компиляторы оптимизируют сейчас сами поидее |
|||
90
Garykom
гуру
10.08.15
✎
15:14
|
(87) и все это без использования очереди?
допустим импульсы всегда одинаковые по длительности (правильные П одной формы) тогда важен только промежуток (интервал) между импульсами на входе берем длину между импульсами (время прошедшее с момента предыдущего) * N и засовываем в очередь на выходе просто берем из очереди, ждем время и выдаем импульс понятно нужны разумные ограничения на величину максимальную и минимальную между импульсами (частоты снизу и сверху) основной цикл работает на выход, и по прерыванию на входящий импульс отрабатывает вход (вычисляет интервал, умножает на N, засовывает в очередь) понятно что будет (может быть точнее) некоторая погрешность на выходе из-за отработки прерывания на входе |
|||
91
Mikeware
10.08.15
✎
15:27
|
(76) а если скважность - не 2? :-)
(80) Брезенхем тут ни при делах...тут гораздо ближе BAM (binary angle modulation). Хотя нужнее паяльник, чтобы вытрясти с ТС ответы на поставленные вопросы. |
|||
92
vde69
10.08.15
✎
16:09
|
(90) нет, ты не понял.... не нужен ццикл,
нужно привязаться к микрухе таймера. для начала отключани диски, потом изменяем адрес прерывания на свою программу, далее изменяем частоту генерация прерывания на нужную. То есть у тебя будет 2 процедуры привязаные к даум разныи прерываниям, первая этл чтение порта и расчет делителя, вторая таймер. Все. |
|||
93
vde69
10.08.15
✎
16:13
|
(92)+ а прогу вешаем в память как резидентную
|
|||
94
Mikeware
10.08.15
✎
16:28
|
(92) в топике ТС говорит о отдельном 8086, не в составе писюке.ниже уже ведёт речь о весьма мелком PICе. Т.е. ТС сам не знает, чего ему надо.
Да, а в стандартном таймере, емнип, три канала, и третьим для генерации можно пользоваться абсолютно невозбранно. |
|||
95
vde69
10.08.15
✎
16:39
|
(94) писюки сильно разные были, я на них собаку сожрал 20 лет назад.
таймеры то-же разные были, в том числе и одноканальные, трехканалки появились примерно с 286х мы в нии делали на хт хитрые анализаторы профиля (типа электронного измерителя размерм). У меня дома книг по сабжу целая полка была. |
|||
96
Garykom
гуру
10.08.15
✎
17:10
|
(92) да можно и через 2 прерывания, но нафига?
если проц не занят больше ничем то лучше в нем гонять цикл корректировки выхода, разные проверки на совпадение времени нужного подачи импульса следующего |
|||
97
Mikeware
10.08.15
✎
17:12
|
(95) 8253 и наш аналог кр580ви53 по жизни были трехканальными. А других просто не было.
|
|||
98
D_Pavel
11.08.15
✎
06:09
|
(80) Кстати, за Брезенхема спасибо, пригодится в другой задаче.
|
|||
99
Mikeware
11.08.15
✎
08:29
|
(98) прежде, чем переходить к другим задачам- может, вы озвучите условия текущей?
|
|||
100
D_Pavel
11.08.15
✎
12:39
|
(99) ок. (0)
|
|||
101
D_Pavel
12.08.15
✎
08:54
|
(75) Сократил процедуру прерывания на два байта. Теперь она всего 7 байт! При каждом вызове выполняется либо 3, либо 6 команд, по условию. Чаще 3, но слабое место когда выполняется 6.
|
|||
102
organizm
12.08.15
✎
09:04
|
БЫСТРОЕ ПРЕОБРАЗОВАНИЕ ФУРЬЕ не предлагать ? Реализаций на разных языках море в интернете, незачем изобретать велосипед.
|
|||
103
D_Pavel
12.08.15
✎
09:10
|
(102) Конечно не предлагать. Представляешь сколько машинных циклов оно займет?
У меня сейчас обрабатывается входящая частота с полупериодом всего 9 машинных циклов. Думаю как избавиться от прерывания, а то из-за него тормозит. |
|||
104
D_Pavel
12.08.15
✎
09:36
|
избавился от прерывания, теперь обрабатывается частота с полупериодом в 8 машинных циклов. Но программа выросла в два раза. Но скорость важнее чем несколько байт.
|
|||
105
D_Pavel
12.08.15
✎
10:30
|
Так как увеличение программы хорошо повлияло на быстродействие, решил не экономить размер программы. Не люблю компромиссы. Упростил все условия, программа растянулась в три раза больше, зато скорость возросла раза в два!!!!
Двукратное увеличение быстродействия ценой 25 байт! Полупериод входящего сигнала сейчас равен 6 машинным циклам! Правда выходной сигнал стал не такой ровный как был при использовании прерывания, потому что с прерыванием отставал от входящего хоть и на большое, но одинаковое количество машинных циклов, а без прерывания на маленькое но разное количество при каждом импульсе. |
|||
106
D_Pavel
14.08.15
✎
06:52
|
(0) Нашел микросхему в которой это реализовано аппаратно. Темку можно закрыть.
|
|||
107
Маратыч
14.08.15
✎
06:55
|
(106) А цинком не поделишься? Вдруг пригодится...
|
|||
108
D_Pavel
14.08.15
✎
07:00
|
||||
109
Mikeware
14.08.15
✎
12:05
|
NCO всего лишь делит частоту. По сути, это один из режимов счётчика, разве что расширенный генерацией меандра кроме строба.. Т.е.то, что уже пр досталось выше.
|
|||
110
fdgd98
14.08.15
✎
12:13
|
(0) в общем надо тебе разобраться с регистрами общего назначения, посмотреть младшие регистры al, bl
|
|||
111
D_Pavel
14.08.15
✎
12:36
|
(110) Спасибо, но мне сказали что сейчас eax, ebx самые лучшие регистры.
|
|||
112
18_plus
14.08.15
✎
12:37
|
(111) тока их нет в 8086
|
|||
113
D_Pavel
14.08.15
✎
12:38
|
(109) В сочетании с простым алгоритмом подсчета параметров для NCO не требующим умножения и деления который я придумал, это мне подходит.
|
|||
114
D_Pavel
14.08.15
✎
12:38
|
(112) Печалька
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |