[net.micro.6809] ident query

emjej@uokvax.UUCP (05/23/84)

#N:uokvax:3500038:000:499
uokvax!emjej    May 23 01:07:00 1984

The other day, I did a

	dump /d0/cmds/ident

on a SSB Level II system, just for the heck of it. Since that
will dump the various text strings that ident uses, and since
ident is nice enough to tell what it thinks a module is based
on the language nibble of the type/language byte in the module
header, one can thus find out what kinds of modules ident
knows about. To my surprise, I found

		C I-code

Am I dreaming/suffering from not seeing what may have been a
preceding BASI?

						James Jones

strick@gatech.UUCP (Henry A. Strickland) (05/29/84)

()
    Concerning the languages that OS9 understands in the module headers ...
    The following language values are defined in my system definitions file:
*
*  Language values
*
  Object    equ  1      6809 object
  Icode     equ  2      Basic09 I-code
  Pcode     equ  3      Pascal P-code
  Ccode     equ  4      C I-code
  CblCode   equ  5      Cobol I-code
  FrtnCode  equ  6      Fortran I-code
 
    My edition of 'ident' knows about all six of these.  ( My C compiler
generates assembly language, which eventually ends up begin a module
of language type object. )
    It's interesting that 'ident' knows about so many languages, but
not very useful unless the 'shell' does, too.  The shell contains a
table of language values and the names of the appropriate interpreters.
Dump your shell, and somewhere around byte $350 to $390 you should
see the object generated by code something like this:

  table     fcb  sbtrn+icode
            fcs  /RunB/
            fcb  prgrm+pcode
            fcs  /PascalS/
            fcb  sbrtn+cblcode         -- cobol, not c
            fcs  /RunC/
            fcb  0
 
    Older versions of the shell may not have the 'sbtrn+' and 'prgrm+'
terms in the 'fcb' lines.  When the shell is ready execute (F$fork) a
module, if the language value is not 'object', it looks in this table
to find the name of the interpreter.  The shell then executes the
interpreter, passing your command line to the interpreter as parameter.
It's rather strange Microware gave my shell the ability to understand a
cobol module, but not fortran or C module (if such a thing exists).  
    If you don't like the choices of languages in your shell, you can
attempt to change them.  Somehow edit the module ( I often write short
basic09 procedures to open a file, seek a place in it, put one byte, &
close it to do quick things like this ) and change the table.  If you
don't plan to use pascal or cobol, you have plenty of room to tamper.
You can make the table shorter (terminate it with the zero) but not
longer.  The table is referenced by a LEAX <TABLE,PCR about 40 to 70
bytes later ( opcodes 308CNN ).  If this was a 16-bit offset, you could
add a new table to the end of the module,  but it's an 8-bit offset,
and it can't point that far.  Before you can use your new shell, you
have to give it a higher revision number in the header, and run it
through the 'verify' command with the 'u' option.  Then use attr
to give it execute permission.  
    Just in case you ever need to ....         strick
-- 
Henry Strickland
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332
CSNet:	Strick @ GATech		ARPA:	Strick.GATech @ CSNet-Relay
uucp:	...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!strick