From owner-freebsd-scsi Mon Mar 11 07:46:19 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA16386 for freebsd-scsi-outgoing; Mon, 11 Mar 1996 07:46:19 -0800 (PST) Received: from Sisyphos (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA16340 for ; Mon, 11 Mar 1996 07:45:54 -0800 (PST) Received: by Sisyphos id AA02742 (5.67b/IDA-1.5); Mon, 11 Mar 1996 15:59:41 +0100 Message-Id: <199603111459.AA02742@Sisyphos> From: se@zpr.uni-koeln.de (Stefan Esser) Date: Mon, 11 Mar 1996 15:59:40 +0100 In-Reply-To: Peter Dufault "Re: NCR disk controller, hp disk" (Mar 11, 6:00) X-Mailer: Mail User's Shell (7.2.6 alpha(2) 7/9/95) To: Peter Dufault Subject: Re: NCR disk controller, hp disk Cc: freebsd-scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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