nabbla (nabbla1) wrote,
nabbla
nabbla1

Category:

QuatCore: вызов процедуры как команда?

Ковыряюсь сейчас с SD-карточкой, и основной код принял такой вот вид:

	SP		StackAddr
	SP		[SP]
	X		Str0Adr
	CALL		print
				
	;ПОСЫЛАЕМ CMD0
InitSD:	X		CMD0strAdr
	CALL		print
	X		CMD0
	CALL		SDsend
	CALL		checkR1
	X		OKCMD0Adr
	CALL		print
				
	;ПОСЫЛАЕМ CMD8
	X		CMD8strAdr
	CALL		print
	X		CMD8
	CALL		SDsend
	CALL		checkR1


и так далее...

Записываем в регистр аргумент для вызова процедуры - и вызываем, и снова аргумент, и снова вызываем.

И подумалось: а нельзя ли как-то так придумать, что команда вида
      print  CMD0strAdr


или

     SDsend CMD8


вызывала бы соответствующую процедуру с нужным аргументом?

И ведь можно, и это даже не будет совсем уж костылём!


Доработка касается исключительно модуля QuatCorePC (program counter, счётчик инструкций). Так выглядят его "адреса источника данных" (SrcAddr):



а так - "адреса получателя" DestAddr:



Сейчас, как это ни странно, для вызова процедуры мы брали QuatCorePC в качестве ИСТОЧНИКА ДАННЫХ - и он выдавал на шину адрес возврата, PC+1, и в качестве "побочного эффекта" прыгал на один из 16 заранее зашитых адреса процедур. И наиболее канонически было в качестве ПОЛУЧАТЕЛЯ ДАННЫХ указать [SP++] - тогда адрес возврата заносится в стек.

Но для записи типа

   print CMD0strAdr


на шину данных поступает аргумент функции.

То есть, мы должны перетащить команды Call0, Call1 и т.д. из SrcAddr в DestAddr. Когда такая команда поступит, мы совершаем переход. Но каким-то образом надо сохранить адрес возврата и аргумент!

Выход только один, наверное: в QuatCorePC вводится ещё два регистра, LR (link register) и AR (argument register). И во время выполнения Call, в первый заносится адрес возврата, а во второй - содержимое шины данных во время вызова.

Далее, если функция не вызывает других функций, то вернуться из неё можно так:

  JMP  LR


а если нужно вызвать другую функцию, то перед вызовом нужно будет занести LR в стек, а возвращать в LR уже не нужно, проще будет сделать
  JMP [--SP]


Видно, что свободных мест в DestAddr для PC не так уж и много: JMP занимает 8 мест, можно у него "откусить" 7 из них. Затем каждая из команд JO/JNO/JL/JGE занимает на один адрес больше, чем могла бы - можно ещё 4 выцарапать. И ещё 3 адреса останется - и всё! И декодирование команд несколько усложнится - больше битов адреса придётся проверять, хотя скорее всего серьёзного "утолщения" не будет.

Из плюсов - принципиально уйдёт проблема с комбинаторными обратными связями по шине данных. Увы, я до сих пор получаю предупреждения, хотя более точный анализ должен был бы показать, что в действительности её там нет - какую комбинацию SrcAddr и DestAddr ни возьми - ничего не выйдет. Но об этом ругается Classic Timing Analyzer, похоже, что он так далеко не закапывается...

И вообще помещение вызова процедуры на стороне Dest вместо Src - куда логичнее.

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


UPD. Кстати, самый первый вариант вызова процедур у меня получался такой:
[SP++] PC
X      print
JMP    [X]

где адрес PC выдавал PC+3, зная, что мы ещё 2 команды проколупаемся :)
К счастью, удалось от этого уйти.

Весь вопрос - может, и на достигнутом останавливаться не надо, и довести до совершенства :) Не думаю, что такая доработка сильно скажется на быстродействии и объёме кода, но писать код будет поприятнее!

Poll #2099121 Вызов процедуры с аргументом

Оно нам надо?

Да
1(100.0%)
Когда больше нечем заняться будет - можно сделать
0(0.0%)
Нет
0(0.0%)
Tags: ПЛИС, программки, работа, странные девайсы
Subscribe

  • Хотел выпендриться

    Одно из замечаний к моему протоколу информационного обмена: ДОБАВЬ 16-битные заголовки к каждому сообщению! Нам могут прислать командное слово с…

  • Моделирование стыковки с помощью ВидеоИзмерителя

    "Нарисовал"-таки видеоролик, где мы начинаем с весьма неблагоприятных условий: вместо того, чтобы нас поставить ровно "напротив" стыковочного узла,…

  • Более тяжёлые тела падают быстрее!

    Увидел не так давно видео от Flammable Maths с таким заголовком, и подумал поначалу - он опять нас троллит. Это немецкий препод математики…

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 0 comments