Date: Mon, 11 Mar 1996 15:59:40 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Peter Dufault <dufault@hda.com> Cc: freebsd-scsi@freebsd.org Subject: Re: NCR disk controller, hp disk Message-ID: <199603111459.AA02742@Sisyphos> In-Reply-To: Peter Dufault <dufault@hda.com> "Re: NCR disk controller, hp disk" (Mar 11, 6:00)
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 11, 6:00, Peter Dufault wrote:
} Subject: Re: NCR disk controller, hp disk
}
} > ... My only complaint
} > about the NCR driver is that the format of the script is very difficult
} > for an "outsider" to interpret which makes it hard for me to
} > lend a hand in fixing bugs...
}
} Last time I talked to Stefan about this he had plans for addressing
} this. Stefan - maybe you should summarize what your thoughts on this
} problem are to the scsi list.
Well, I think I sent a private reply to you
last time, and didn't send this to any list.
I just want to show the proposed format,
compared to NCR SCRIPTS and the current code.
First a short example in the current format:
SCR_FROM_REG (sdid),
0,
SCR_TO_REG (ctest0),
0,
SCR_MOVE_TBL ^ SCR_MSG_OUT,
offsetof (struct dsb, smsg),
SCR_CLR (SCR_ATN),
0,
SCR_COPY (1),
RADDR (sfbr),
NADDR (lastmsg),
SCR_COPY (4),
RADDR (scratcha),
PADDR (startpos),
Changing any part of the microcode requires
adjusting a length value at the head of the
script.
Now NCR SCRIPTS, the official way to write
code for the NCR:
select_NEXT:
move sdid to sfbr
move sfbr to ctest0
move table(smsg), with msg_out
clear atn
move memory 1, pass(chip_physaddr+sfbr), lastmsg
move memory 1, pass(chip_physaddr+scratcha), startpos
I do not like this syntax for several reasons,
but I think it is easy to support, once my
proposed new format is implemented:
LoadSfbr (sdid)
StoreSfbr (ctest0)
Move (Table, MSG_OUT, smsg)
Clear (Atn)
Copy (1, sfbr, lastmsg)
Copy (4, scratcha, STARTPOS)
The difference to NCR SCRIPTS is:
1) My format will be suitable to initialize
an array of bytes from C preprocessor
constructs. This requires brackets around
the arguments.
2) The format does not suggest the existance
of commands, that actually aren't interpreted.
The SFBR register is kind of an accumulator,
for example, and SCRIPTS doesn't syntactically
differentiate between commands with very
different semantics.
But I consider a Perl script that translates
from SCRIPTS into my proposed format trivial,
and may even provide you with a proof some time :)
The advantages compared to the old format:
1) Much more compact (many commands will require
only one or two bytes in the new representation,
while the expanded command is 8 or 12 bytes long).
2) More readable
3) Allows run-time binding of modules. This is
required for support of the advanced NCR chips.
E.g. I'll have a "Fast" pseudo-command, which
will inidcate to the run-time loader, that the
following commands should be placed into the
SRAM within the NCR chip, were present (applies
to the 53c825A and 53c875). Without this run-time
binding phase, the complete NCR microcode must
be present in the driver in all variations, and
it takes up some 4KB per chip type ...
I have converted the complete NCR microcode to the
new format, and I have started to define the macro
constructs, that will generate the internal byte-code
representation, that will be expanded and bound by
the driver init code.
Eg.:
#define MSG_OUT 6
#define MSG_IN 7
#define LABELSTART 0x1000
#define When 0x80 |
#define If 0x40 |
#define Not 0x20 |
#define Phase(phase) (phase)
#define Jump(label) 0x01, (label - LABELSTART),
This makes
When Phase (MSG_IN) Jump (DO_MSGIN)
come out as
unsigned char demoscript[] = {
0x80 | (7), 0x01, 0x1005 - 0x1000,
};
The most complex problem is in the binding
phase. Symbols must be exported to the
driver code, since the CPU must be able
to access shared variables. The CPU must
patch a few NCR instructions, e.g. the
run queue is implemented as a circular
queue, where a JUMP IDLE gets replaced
by a JUMP START when a new command control
block has been prepared ...
The proposed method has got its limitations,
but I think I can live with them.
Regards, STefan
--
Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021
Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160
==============================================================================
http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603111459.AA02742>