| 1 | .\" Automatically generated by Pod::Man v1.34, Pod::Parser v1.13 |
| 2 | .\" |
| 3 | .\" Standard preamble: |
| 4 | .\" ======================================================================== |
| 5 | .de Sh \" Subsection heading |
| 6 | .br |
| 7 | .if t .Sp |
| 8 | .ne 5 |
| 9 | .PP |
| 10 | \fB\\$1\fR |
| 11 | .PP |
| 12 | .. |
| 13 | .de Sp \" Vertical space (when we can't use .PP) |
| 14 | .if t .sp .5v |
| 15 | .if n .sp |
| 16 | .. |
| 17 | .de Vb \" Begin verbatim text |
| 18 | .ft CW |
| 19 | .nf |
| 20 | .ne \\$1 |
| 21 | .. |
| 22 | .de Ve \" End verbatim text |
| 23 | .ft R |
| 24 | .fi |
| 25 | .. |
| 26 | .\" Set up some character translations and predefined strings. \*(-- will |
| 27 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left |
| 28 | .\" double quote, and \*(R" will give a right double quote. | will give a |
| 29 | .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to |
| 30 | .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' |
| 31 | .\" expand to `' in nroff, nothing in troff, for use with C<>. |
| 32 | .tr \(*W-|\(bv\*(Tr |
| 33 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' |
| 34 | .ie n \{\ |
| 35 | . ds -- \(*W- |
| 36 | . ds PI pi |
| 37 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch |
| 38 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch |
| 39 | . ds L" "" |
| 40 | . ds R" "" |
| 41 | . ds C` "" |
| 42 | . ds C' "" |
| 43 | 'br\} |
| 44 | .el\{\ |
| 45 | . ds -- \|\(em\| |
| 46 | . ds PI \(*p |
| 47 | . ds L" `` |
| 48 | . ds R" '' |
| 49 | 'br\} |
| 50 | .\" |
| 51 | .\" If the F register is turned on, we'll generate index entries on stderr for |
| 52 | .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index |
| 53 | .\" entries marked with X<> in POD. Of course, you'll have to process the |
| 54 | .\" output yourself in some meaningful fashion. |
| 55 | .if \nF \{\ |
| 56 | . de IX |
| 57 | . tm Index:\\$1\t\\n%\t"\\$2" |
| 58 | .. |
| 59 | . nr % 0 |
| 60 | . rr F |
| 61 | .\} |
| 62 | .\" |
| 63 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes |
| 64 | .\" way too many mistakes in technical documents. |
| 65 | .hy 0 |
| 66 | .if n .na |
| 67 | .\" |
| 68 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
| 69 | .\" Fear. Run. Save yourself. No user-serviceable parts. |
| 70 | . \" fudge factors for nroff and troff |
| 71 | .if n \{\ |
| 72 | . ds #H 0 |
| 73 | . ds #V .8m |
| 74 | . ds #F .3m |
| 75 | . ds #[ \f1 |
| 76 | . ds #] \fP |
| 77 | .\} |
| 78 | .if t \{\ |
| 79 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) |
| 80 | . ds #V .6m |
| 81 | . ds #F 0 |
| 82 | . ds #[ \& |
| 83 | . ds #] \& |
| 84 | .\} |
| 85 | . \" simple accents for nroff and troff |
| 86 | .if n \{\ |
| 87 | . ds ' \& |
| 88 | . ds ` \& |
| 89 | . ds ^ \& |
| 90 | . ds , \& |
| 91 | . ds ~ ~ |
| 92 | . ds / |
| 93 | .\} |
| 94 | .if t \{\ |
| 95 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" |
| 96 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' |
| 97 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' |
| 98 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' |
| 99 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' |
| 100 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' |
| 101 | .\} |
| 102 | . \" troff and (daisy-wheel) nroff accents |
| 103 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' |
| 104 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' |
| 105 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] |
| 106 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' |
| 107 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' |
| 108 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] |
| 109 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] |
| 110 | .ds ae a\h'-(\w'a'u*4/10)'e |
| 111 | .ds Ae A\h'-(\w'A'u*4/10)'E |
| 112 | . \" corrections for vroff |
| 113 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' |
| 114 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' |
| 115 | . \" for low resolution devices (crt and lpr) |
| 116 | .if \n(.H>23 .if \n(.V>19 \ |
| 117 | \{\ |
| 118 | . ds : e |
| 119 | . ds 8 ss |
| 120 | . ds o a |
| 121 | . ds d- d\h'-1'\(ga |
| 122 | . ds D- D\h'-1'\(hy |
| 123 | . ds th \o'bp' |
| 124 | . ds Th \o'LP' |
| 125 | . ds ae ae |
| 126 | . ds Ae AE |
| 127 | .\} |
| 128 | .rm #[ #] #H #V #F C |
| 129 | .\" ======================================================================== |
| 130 | .\" |
| 131 | .IX Title "MIDASFORMAT 1" |
| 132 | .TH MIDASFORMAT 1 "2007-01-08" "perl v5.8.0" "User Contributed Perl Documentation" |
| 133 | .SH "NAME" |
| 134 | midasformat \- Format for diags recognized by \fBmidas\fR |
| 135 | .SH "DESCRIPTION" |
| 136 | .IX Header "DESCRIPTION" |
| 137 | This document describes the format of diags that can be assembled by |
| 138 | \&\fBmidas\fR. Note that this is not a guide for writing diags, since it |
| 139 | makes no assumptions about the contents of project-standard include |
| 140 | files or boot code. |
| 141 | .Sh "Source Languages" |
| 142 | .IX Subsection "Source Languages" |
| 143 | \&\fBMidas\fR can assemble diags in the following formats: |
| 144 | .IP "Augmented Assembly" 4 |
| 145 | .IX Item "Augmented Assembly" |
| 146 | The main supported source language, denoted with a .s extension on the |
| 147 | source file, is an augmented \s-1SPARC\s0 assembly file. By \*(L"augmented\*(R", we |
| 148 | refer to several directives used to program the \s-1MMU\s0. These directives |
| 149 | are interpreted by \fBmidas\fR, and their presence means that the raw diag, |
| 150 | even though it ends in .s, would not be acceptable input to a standard |
| 151 | assembler. |
| 152 | .Sp |
| 153 | An assembly diag should be one file, though it may #include others. A |
| 154 | diag may also contain a perl script, used by the simulation framework |
| 155 | to do postprocessing on the diag's output. \fBMidas\fR scans a diag for the |
| 156 | symbol \*(L"_\|_PERL_\|_\*(R" on a line by itself. If it finds such a symbol, |
| 157 | then everything after the _\|_PERL_\|_ line is taken to be a perl script |
| 158 | and is not assembled. |
| 159 | .IP "\s-1PAL\s0 (perl augmented language)" 4 |
| 160 | .IX Item "PAL (perl augmented language)" |
| 161 | A diag that ends in a .pal extension is assumed to be written in \s-1PAL\s0 |
| 162 | (perl augmented language). The diag is run through the \s-1PAL\s0 |
| 163 | preprocessor, and the output of \s-1PAL\s0 should be an augmented assembly |
| 164 | file as described above. \fBMidas\fR takes care of running the \s-1PAL\s0 |
| 165 | preprocesing phase if the diag ends in .pal. Since \s-1PAL\s0 and assembly |
| 166 | diags are treated identically after \s-1PAL\s0 preprocessing, the remainder |
| 167 | of the this document discusses only assembly diags. |
| 168 | .IP "C" 4 |
| 169 | .IX Item "C" |
| 170 | The top-level diag file is always an augmented assembly file (or a \s-1PAL\s0 |
| 171 | script that generated an augmented assembly file), but there are |
| 172 | directives to include C programs in a diag. See the \*(L"High Level Languages\*(R" section. |
| 173 | .IP "Object files (.o) and Library files (.a)" 4 |
| 174 | .IX Item "Object files (.o) and Library files (.a)" |
| 175 | As with C files, raw object (.o) files and static library (.a) files |
| 176 | may be included in a diag. See the \*(L"High Level Languages\*(R" |
| 177 | section. |
| 178 | .IP "Linked Executables" 4 |
| 179 | .IX Item "Linked Executables" |
| 180 | These can be included as-is in a diag. See the \*(L"\s-1APPLICATION\s0\*(R" |
| 181 | section. |
| 182 | .Sh "Output Files" |
| 183 | .IX Subsection "Output Files" |
| 184 | The following output files are generated by \fBmidas\fR: (the names of the |
| 185 | output files can be reconfigured, but these are the default names) |
| 186 | .IP "\fImem.image\fR" 4 |
| 187 | .IX Item "mem.image" |
| 188 | The \fImem.image\fR file is the main output of \fBmidas\fR. It contains the |
| 189 | initial contents of physical memory in a verilog memory-image format. |
| 190 | The format consists lines containing "@<physical_address>", |
| 191 | followed by lines of data to write at that address. |
| 192 | .IP "\fIdiag.ev\fR" 4 |
| 193 | .IX Item "diag.ev" |
| 194 | This is an event file generated for vera. Any assembly line that |
| 195 | contains a comment that begins with \*(L"$EV\*(R" will generate an entry in |
| 196 | this file. \fI\s-1XXX\s0 \- this format should be documented further.\fR |
| 197 | .IP "\fIsymbol.tbl\fR" 4 |
| 198 | .IX Item "symbol.tbl" |
| 199 | This file contains 4 columns: symbol_name, virtual_addres, real |
| 200 | address, and physical_address. It exists to support the simulation |
| 201 | framework so it can lookup addresses for symbol names. If any of the |
| 202 | addresses are inappropriate (such as real address for unmapped |
| 203 | sections), it will be represented by 'X'. |
| 204 | .IP "\fIdiag.pl\fR" 4 |
| 205 | .IX Item "diag.pl" |
| 206 | This is a perl script extracted from the diag (i.e., the code after |
| 207 | the \*(L"_\|_PERL_\|_\*(R" directive). It is used by the simulation framework to |
| 208 | do diag-specific post\-processing. |
| 209 | .IP "\fIdiag*.exe\fR" 4 |
| 210 | .IX Item "diag*.exe" |
| 211 | This is the linked executable built by \fBmidas\fR (the * is the name of |
| 212 | the application, if there is a non-default application). It is not |
| 213 | used by the simulation framework, but it can be useful, for instance, |
| 214 | for disassembly. |
| 215 | .SH "BUILD PROCESS" |
| 216 | .IX Header "BUILD PROCESS" |
| 217 | This section is an overview of how a diag is processed to produce |
| 218 | \&\fImem.image\fR. |
| 219 | .Sh "Preprocessing" |
| 220 | .IX Subsection "Preprocessing" |
| 221 | Diags are run through several preprocessing steps that enable complex |
| 222 | macro environments to perform diag setup. Such macro environments are |
| 223 | not part of \fBmidas\fR and are therefore beyond the scope of this document. |
| 224 | .IP "Split perl and assembly" 4 |
| 225 | .IX Item "Split perl and assembly" |
| 226 | The first preprocessing step is to split the diag into assembly and |
| 227 | perl parts. \fBMidas\fR assumes that the diag is entirely assembly |
| 228 | unless it encounters the symbol \*(L"_\|_PERL_\|_\*(R" on a line by itself. If it |
| 229 | sees this symbol, then everything after it assumed to be a perl |
| 230 | script. The output of this phase are files in the build directory: |
| 231 | \&\fIdiag.s\fR and, if necessary, \fIdiag.pl\fR. |
| 232 | .IP "\fBcpp\fR" 4 |
| 233 | .IX Item "cpp" |
| 234 | The next step is to run the diag through the C preprocessor. Most |
| 235 | diags will #include their boot code and perhaps some project-specific |
| 236 | definitions. Diags can also #define symbols before including the boot |
| 237 | code to configure its operation. Note that this is a Sun, not a \s-1GNU\s0, |
| 238 | preprocessor, which means that \s-1GNU\s0 extensions to cpp (such as |
| 239 | preprocessor directives where the '#' isn't in column 1) cannot be |
| 240 | used. For information the default include path, consult the \fBmidas\fR |
| 241 | man page. The output of this stage is a file in the build directory |
| 242 | called \fIdiag.cpp\fR. |
| 243 | .IP "\fBm4\fR" 4 |
| 244 | .IX Item "m4" |
| 245 | After \fBcpp\fR, the diag is processed by \fBm4\fR. This allows macro |
| 246 | preprocessing that is substantially more powerful than what is |
| 247 | possible with \fBcpp\fR. The content of these macros is |
| 248 | project\-specific. The version of \fBm4\fR used by \fBmidas\fR is special in |
| 249 | that it was compiled to allow 64\-bit arithmetic via the \f(CW\*(C`mpeval\*(C'\fR |
| 250 | directive. The output of this stage is a file in the build directory |
| 251 | called \fIdiag.m4\fR. |
| 252 | .IP "Sectioning" 4 |
| 253 | .IX Item "Sectioning" |
| 254 | A diag is made up of sections. Each section may contain a text, data, |
| 255 | bss or other segments. The defining characteristic of a section is |
| 256 | that each segment is contiguous in the virtual address space (i.e., |
| 257 | the text segment is contiguous and so is the data segment, but they |
| 258 | need not be contiguous with each other). A section begins with a |
| 259 | \&\f(CW\*(C`SECTION\*(C'\fR directive at the beginning of a line. The \f(CW\*(C`SECTION\*(C'\fR line |
| 260 | defines the section's name and optionally some parameters. Any data |
| 261 | or code appearing after a \f(CW\*(C`SECTION\*(C'\fR directive belongs to that |
| 262 | section, until the next \f(CW\*(C`SECTION\*(C'\fR directive is encountered. Any code |
| 263 | or data before the first \f(CW\*(C`SECTION\*(C'\fR directive is part of the first |
| 264 | section. |
| 265 | .Sp |
| 266 | If a \s-1SECTION\s0 line appears for a section that has previously been |
| 267 | defined, the meaning is to append to the existing section. It is |
| 268 | illegal to have SECTION-line arguments for any but the first |
| 269 | definition of a section. Note that it simply appends to the existing |
| 270 | section, so be sure to begin your appended version with a .text or |
| 271 | \&.data assembly directive, as appropriate. |
| 272 | .Sp |
| 273 | Sections are linked at a specific, user-defined address. Linker |
| 274 | scripts require that each section be in a separte file. The |
| 275 | sectioning phase, therefore, extracts the \f(CW\*(C`SECTION\*(C'\fR directives from |
| 276 | the assembly file and writes \*(L"pure\*(R" assembly files for each section. |
| 277 | By \*(L"pure\*(R", we mean that these files have no \fBmidas\fR\-specific |
| 278 | directives and can therefore be assembled directly. |
| 279 | .Sp |
| 280 | The output of this phase are a series of files in the build directory, |
| 281 | one for each section. Their names are |
| 282 | \&\fIsec<num>.<secname>.s\fR. The sectioning phase also |
| 283 | produces the file 'diag.midas' which contains all of the midas |
| 284 | directives. Midas then parses this file, and leaves the others to the |
| 285 | assembler. |
| 286 | .Sh "Assembly" |
| 287 | .IX Subsection "Assembly" |
| 288 | Each section written by the sectioning phase above is assembled via |
| 289 | the \s-1GNU\s0 assembler. The output is a .o file. |
| 290 | .Sh "Link executable" |
| 291 | .IX Subsection "Link executable" |
| 292 | All object files are linked, using the \s-1GNU\s0 loader. Each section is |
| 293 | linked at the virtual address defined in its section header. The |
| 294 | output of this phase is \fIdiag.exe\fR. |
| 295 | .Sh "PostProcessing" |
| 296 | .IX Subsection "PostProcessing" |
| 297 | After the diag is linked, the following postprocessing is done: |
| 298 | .IP "Generate \fImem.image\fR" 4 |
| 299 | .IX Item "Generate mem.image" |
| 300 | Generation of \fImem.image\fR is done a section at a time, not by simply |
| 301 | disassembling \fIdiag.exe\fR. The reason is that \fImem.image\fR should |
| 302 | represent the initial contents of physical memory, which may or may |
| 303 | not be a simple dump of the text and data segments for each section. |
| 304 | For most diags, this will simply be a hex dump of \fIdiag.exe\fR (with |
| 305 | the sections linked at the appropriate physical addresses, as defined |
| 306 | by the section header). How exactly the \s-1MMU\s0 constructs \fImem.image\fR |
| 307 | is controlled by the section header, which is described in detail in |
| 308 | the next section. Generation of \fImem.image\fR is handled by |
| 309 | \&\fBgoldfinger\fR. |
| 310 | .IP "Generate \fIsymbol.tbl\fR" 4 |
| 311 | .IX Item "Generate symbol.tbl" |
| 312 | To generate the symbol table, the \fIdiag.exe\fR file is examined to find |
| 313 | virtual addresses for each symbol. The \s-1MMU\s0 is then used to do the |
| 314 | virtual-to-physical translation and write the \fIsymbol.tbl\fR file. |
| 315 | Generation of \fIsymbol.tbl\fR is handled by \fBgoldfinger\fR. |
| 316 | .IP "Generate \fIdiag.ev\fR" 4 |
| 317 | .IX Item "Generate diag.ev" |
| 318 | The \fIdiag.ev\fR file is generated by examining the diag source for |
| 319 | comments containing \f(CW$EV\fR. These are then cross-referenced with |
| 320 | \&\fIsymbol.tbl\fR to producde \fIdiag.ev\fR. |
| 321 | .SH "DIAG FORMAT" |
| 322 | .IX Header "DIAG FORMAT" |
| 323 | A diag consists of applications and sections within those |
| 324 | applications. Diags may also contain TSBs. |
| 325 | .Sh "\s-1APPLICATION\s0" |
| 326 | .IX Subsection "APPLICATION" |
| 327 | An application begins with: |
| 328 | .PP |
| 329 | .Vb 1 |
| 330 | \& APPLICATION <name> [FILE=<filename>] |
| 331 | .Ve |
| 332 | .PP |
| 333 | An application defines a single linked executable. All SECTIONs that |
| 334 | follow are linked into this application. A linked executable is just |
| 335 | an intermediate file in \fImem.image\fR generation, so an \s-1APPLICATION\s0 |
| 336 | directive affects only relocation and the scope of labels. All diags |
| 337 | have at least one application, even if none is defined, since all |
| 338 | diags are treated as if their first line were: |
| 339 | .PP |
| 340 | .Vb 1 |
| 341 | \& APPLICATION default |
| 342 | .Ve |
| 343 | .PP |
| 344 | If the optional filename is given, then that file is taken as the |
| 345 | linked executable to use. The link path is searched to find a file by |
| 346 | this name. This is how you can include a linked executable that was |
| 347 | not generated by \fBmidas\fR. |
| 348 | .PP |
| 349 | \fIgoldfinger_cmd blocks\fR |
| 350 | .IX Subsection "goldfinger_cmd blocks" |
| 351 | .PP |
| 352 | There is currently no way to specify address translations and |
| 353 | \&\fImem.image\fR contents for applications that midas does not generate. |
| 354 | As the tool matures, I plan to invent an interface. In the meantime, |
| 355 | you can include a goldfinger_cmd block. Such a block begins a line |
| 356 | with \*(L"goldfinger_cmd\*(R" and an open curly\-brace. It ends with the |
| 357 | closed\-curly. The contents of the block are not interpreted \fBmidas\fR |
| 358 | at all. They are simply copied into \fIdiag.goldfinger\fR inside the |
| 359 | currently open application. |
| 360 | .PP |
| 361 | An example: |
| 362 | .PP |
| 363 | .Vb 22 |
| 364 | \& goldfinger_cmd { |
| 365 | \& BLOCK .main_text_0 |
| 366 | \& SECTION_NAME = ".MAIN"; |
| 367 | \& SEGMENT_NAME = "text"; |
| 368 | \& LINK_SECTION = "sec7.maint"; |
| 369 | \& SRC_FILE = "diag.m4"; |
| 370 | \& SRC_LINE = 5398; |
| 371 | \& COMPRESS = 0; |
| 372 | \& VA = 0x0000000020000000; |
| 373 | \& RA = 0x0130000000; |
| 374 | \& PA = 0x1130000000; |
| 375 | \& IN_IMAGE = 1; |
| 376 | \& BLOCK_TSB part_0_i_ctx_nonzero_ps0_tsb |
| 377 | \& page_size = 8192; |
| 378 | \& va_index_bits = 21 : 13; |
| 379 | \& tag_addr_bits = 63 : 13; |
| 380 | \& data_addr_bits = 39 : 13; |
| 381 | \& tag_base = 0x0000000000000044; |
| 382 | \& data_base = 0x8000000000000440; |
| 383 | \& END BLOCK_TSB |
| 384 | \& END BLOCK |
| 385 | \& } |
| 386 | .Ve |
| 387 | .PP |
| 388 | Note that until the tool matures, the \fBmidas\fR\-\fBgoldfinger\fR interface |
| 389 | may change, so this syntax is deprecated, but it can be useful in a |
| 390 | pinch. |
| 391 | .Sh "\s-1SECTION\s0 Definitions" |
| 392 | .IX Subsection "SECTION Definitions" |
| 393 | A \s-1SECTION\s0 defines a region of the diag that may contain up to 3 |
| 394 | segments: text, data, and bss. Each of these segments is contiguous |
| 395 | in the virtual address space (but not necessarily in the real or |
| 396 | physical address spaces). Note that the \fBmidas\fR terminology is |
| 397 | different from the \fB\s-1ELF\s0\fR terminology. Each segment in \fBmidas\fR |
| 398 | terminology corresponds to an \fB\s-1ELF\s0\fR section. |
| 399 | .PP |
| 400 | .Vb 1 |
| 401 | \& SECTION <name> [section_args] |
| 402 | .Ve |
| 403 | .PP |
| 404 | When a section directive is encountered, all assembly code (and data) |
| 405 | that follows is placed in that section, until the next \s-1SECTION\s0 |
| 406 | directive is encountered. |
| 407 | .PP |
| 408 | The \f(CW\*(C`SECTION\*(C'\fR header affects the text and data segments that follow |
| 409 | it, until another \f(CW\*(C`SECTION\*(C'\fR header is reached. As a special case, |
| 410 | all code and data in the assembly file before the first \f(CW\*(C`SECTION\*(C'\fR |
| 411 | header belongs to the first section. A \s-1SECTION\s0 line may be split |
| 412 | across multiple lines of input by escaping the newline with a \e. |
| 413 | .PP |
| 414 | The section_args should define the virtual addresses at which to link |
| 415 | the various segments. This is done by a comma-separated list such as: |
| 416 | .PP |
| 417 | .Vb 2 |
| 418 | \& SECTION .MAIN TEXT_VA=0x20000000, DATA_VA=0x60000000, \e |
| 419 | \& BSS_VA=0x68030000 |
| 420 | .Ve |
| 421 | .PP |
| 422 | Any of the virtual addresses may be ommitted, but if they are, that |
| 423 | segment will not be included in the link. The *_VA symbols are all |
| 424 | case\-insensitive. The addresses themselves are assumed to be 64\-bit |
| 425 | decimal numbers, unless they start with 0x (in which case they are |
| 426 | 64\-bit hex numbers). |
| 427 | .PP |
| 428 | See the section on \*(L"\s-1ADDRESS\s0 \s-1TRANSLATIONS\s0\*(R" for details on how |
| 429 | address translations can be specified for the segments in a section. |
| 430 | Note that unless address translations are specified, there is no |
| 431 | physical address to place segments in the \fImem.image\fR file! |
| 432 | .Sh "\s-1TSB\s0 \s-1OBJECT\s0 \s-1DEFINITIONS\s0" |
| 433 | .IX Subsection "TSB OBJECT DEFINITIONS" |
| 434 | A \s-1TSB\s0 object is decared with the following syntax: |
| 435 | .PP |
| 436 | .Vb 1 |
| 437 | \& MIDAS_TSB <name> <register> [args] |
| 438 | .Ve |
| 439 | .PP |
| 440 | This defines a \s-1TSB\s0 with the specified name, which is initialized by |
| 441 | the config register <register>. It will be instantiated in |
| 442 | the memory image if any attr block tries to use it. All \s-1MMU\s0 types get |
| 443 | a base address and \s-1TSB\s0 size from the config register as defined in |
| 444 | their \s-1PRM\s0. Niagara\-2, in addition, parses a page size (same meaning |
| 445 | as the page_size optional argument below) and sun4u/sun4v, which will |
| 446 | be used instead of the global default for ttefmt. Note that if you |
| 447 | provide the optional arguments page_size and/or ttefmt for Niagara\-2, |
| 448 | the optional arguments will override the config register. |
| 449 | .PP |
| 450 | The optional args can be: |
| 451 | .IP "link=<name>" 4 |
| 452 | .IX Item "link=<name>" |
| 453 | Use the specified name as a link area. This is used in the case of |
| 454 | \&\s-1TSB\s0 collisions to hold a linked list. There must be \s-1MIDAS_TSB_LINK\s0 |
| 455 | declaration by this name. |
| 456 | .IP "force_ctx_zero" 4 |
| 457 | .IX Item "force_ctx_zero" |
| 458 | If this is specified, then any entries added to this \s-1TSB\s0 will have |
| 459 | context bits of zero, regardless of how they are specified in the attr blocks. |
| 460 | .IP "page_size=<codedSize>" 4 |
| 461 | .IX Item "page_size=<codedSize>" |
| 462 | This defines a default page size for all entries that are added to the |
| 463 | \&\s-1TSB\s0. This will be used if no TTE_Size_Ptr values are given for the |
| 464 | entries. The coded size is the same encoding used in the TTE_Size |
| 465 | field. |
| 466 | .IP "way=<way>" 4 |
| 467 | .IX Item "way=<way>" |
| 468 | If a \s-1TSB\s0 is split (which only applies to the \*(L"ultra2\*(R" and \*(L"niagara\*(R" |
| 469 | \&\s-1MMU\s0 types), this is specified to midas by creating two TSBs that have |
| 470 | the same value of the config register with the split bit set. Midas |
| 471 | treats each half of the \s-1TSB\s0 separately. This makes it easy for diags |
| 472 | to control which half of the split \s-1TSB\s0 gets each translation. The way |
| 473 | definition on the \s-1TSB\s0 line tells midas which half of the split \s-1TSB\s0 |
| 474 | applies to this definition. The only legal settings are \*(L"way=0\*(R" and |
| 475 | \&\*(L"way=1\*(R". If way is set to zero, the \s-1TSB\s0 is configured just as if it |
| 476 | were not split. If way is set to one, then the base address is |
| 477 | modifed internally so that it starts after the way=0 \s-1TSB\s0 would end. |
| 478 | The way setting is ignored if the \s-1TSB\s0 is not split or if the \s-1MMU\s0 type |
| 479 | does not support split TSBs. It is the responsibility of the diag |
| 480 | writer to make sure that the two halves of a split \s-1TSB\s0 are configured |
| 481 | in a compatible fashion (both sides having split bit on and the same |
| 482 | base address). |
| 483 | .IP "ttefmt=<format>" 4 |
| 484 | .IX Item "ttefmt=<format>" |
| 485 | Sets the format for this \s-1TSB\s0 to the specified format (either sun4u or |
| 486 | sun4v). This setting will be used instead of the default value of |
| 487 | \&\-ttefmt. |
| 488 | .Sh "\s-1TSB_LINK\s0 \s-1OBJECT\s0 \s-1DEFINITIONS\s0" |
| 489 | .IX Subsection "TSB_LINK OBJECT DEFINITIONS" |
| 490 | A \s-1TSB_LINK\s0 object is an area used to store linked lists in the case of |
| 491 | collisions in the \s-1TSB\s0. Multiple TSBs can share a \s-1TSB_LINK\s0. The |
| 492 | syntax is: |
| 493 | .PP |
| 494 | .Vb 1 |
| 495 | \& MIDAS_TSB_LINK <name> <pa> |
| 496 | .Ve |
| 497 | .PP |
| 498 | This declares a \s-1TSB_LINK\s0 object that will start at the specified \s-1PA\s0. |
| 499 | It will be instantiated in the memory image if any \s-1TSB\s0 that uses it is |
| 500 | instantiated. |
| 501 | .Sh "\s-1ADDRESS\s0 \s-1TRANSLATIONS\s0" |
| 502 | .IX Subsection "ADDRESS TRANSLATIONS" |
| 503 | Address translations are created by attr_ blocks. The name of the |
| 504 | block defines the segment on which the block operates. They syntax is: |
| 505 | .PP |
| 506 | .Vb 6 |
| 507 | \& attr_<segment_name> { |
| 508 | \& name|section=<name>, |
| 509 | \& <key>=<val>, <key>=<val>, |
| 510 | \& <key>=<val> |
| 511 | \& ... |
| 512 | \& } |
| 513 | .Ve |
| 514 | .PP |
| 515 | The <segment_name> may be \*(L"text\*(R", \*(L"data\*(R", or \*(L"bss\*(R". Each attr |
| 516 | block must specify which \s-1SECTION\s0 they belong to. They do this by |
| 517 | setting name= or section= inside the block. This means the attr block |
| 518 | itself may appear anywhere in the diag, not necessarily lexically |
| 519 | inside the section. The blocks are matched to the sections by name, |
| 520 | which is case\-insensitive. |
| 521 | .PP |
| 522 | The contents of the block are a list of key=value pairs (name|section= |
| 523 | just being a special case). These pairs can be separated by commas |
| 524 | and/or newlines. Key names are case\-insensitive. A \s-1TSB\s0 name may |
| 525 | appear as a key with no value. If any other key appears with no |
| 526 | =value, the value is assumed to be 1. |
| 527 | .PP |
| 528 | An example of an attr block is: |
| 529 | .PP |
| 530 | .Vb 10 |
| 531 | \& attr_text { |
| 532 | \& Name = .TRAPS, |
| 533 | \& RA = 0x120000, |
| 534 | \& PA = 0x1000120000, |
| 535 | \& part_0_i_ctx_zero_ps0_tsb, |
| 536 | \& TTE_Context=0, TTE_V=1, TTE_Size=0, |
| 537 | \& TTE_NFO=0, TTE_IE=0, TTE_Soft2=0, TTE_Diag=0, |
| 538 | \& TTE_Soft=0, TTE_L=0, TTE_CP=1, TTE_CV=0, |
| 539 | \& TTE_E=0, TTE_P=1, TTE_W=1 |
| 540 | \& } |
| 541 | .Ve |
| 542 | .PP |
| 543 | An attr block has two purposes: setting up \s-1TSB\s0 mappings and writing to |
| 544 | \&\fImem.image\fR. It therefore needs to contain enough information to: |
| 545 | .IP "Select a subset of the segment" 4 |
| 546 | .IX Item "Select a subset of the segment" |
| 547 | An attr block need not define the same translation for an entire |
| 548 | segment, and it may define a subset of the segment on which to |
| 549 | operated. |
| 550 | .IP "Physical address" 4 |
| 551 | .IX Item "Physical address" |
| 552 | This defines where to write the segment (or segment subset) in the |
| 553 | \&\fImem.image\fR. |
| 554 | .IP "Define \s-1TSB\s0 parameters" 4 |
| 555 | .IX Item "Define TSB parameters" |
| 556 | These include a list of TSBs that should contain translations for this |
| 557 | section, an \s-1RA\s0 (real address) that should be included in the \s-1TSB\s0, and |
| 558 | \&\s-1TTE\s0 elements. The exact details may be processor\-specific. It is |
| 559 | controlled by the mmu type. Note that for MMUs that do not have |
| 560 | two-level address translation (i.e., \*(L"ultra2\*(R"), there is no \s-1RA\s0, so \s-1PA\s0 |
| 561 | is used for TSBs instead. |
| 562 | .PP |
| 563 | \fISelecting a subset\fR |
| 564 | .IX Subsection "Selecting a subset" |
| 565 | .PP |
| 566 | Selecting a subset consits of defining a starting and stopping virtual |
| 567 | address for the block. |
| 568 | .PP |
| 569 | Defining the starting virtual address |
| 570 | .IX Subsection "Defining the starting virtual address" |
| 571 | .IP "start_label" 4 |
| 572 | .IX Item "start_label" |
| 573 | If the key \f(CW\*(C`start_label\*(C'\fR exists it must be a label inside the |
| 574 | segment. It is used as the beginning of the attr block. It must be a |
| 575 | page-aligned address unless the block is not being entered into a \s-1TSB\s0. |
| 576 | .IP "\s-1VA\s0" 4 |
| 577 | .IX Item "VA" |
| 578 | The attr block may explicitly define a starting virtual address using |
| 579 | the tag \f(CW\*(C`VA\*(C'\fR. It is an error if this virtual address is not a |
| 580 | page-aligned address within the segment (if the block is not writing a |
| 581 | \&\s-1TSB\s0 entry the alignment contraint is relaxed). For this reason, the |
| 582 | start_label syntax is the preferred one for most diags. |
| 583 | .IP "\fIdefault\fR" 4 |
| 584 | .IX Item "default" |
| 585 | If neither \s-1VA\s0 nor start_label are specified for an attr block, the |
| 586 | starting \s-1VA\s0 for the segment is used. |
| 587 | .PP |
| 588 | Defining the ending virtual address |
| 589 | .IX Subsection "Defining the ending virtual address" |
| 590 | .PP |
| 591 | There are three ways to define the ending address for an attr block. |
| 592 | .IP "end_label" 4 |
| 593 | .IX Item "end_label" |
| 594 | If \f(CW\*(C`end_label\*(C'\fR is defined, it must be label inside the segment (and |
| 595 | of course, it must appear after the starting \s-1VA\s0). The \f(CW\*(C`attr_text\*(C'\fR |
| 596 | definiton ends at the address of the label. The address need not be |
| 597 | page\-aligned. |
| 598 | .IP "end_va" 4 |
| 599 | .IX Item "end_va" |
| 600 | The attr block may explicitly define an ending virtual address. It is |
| 601 | an error if this address is not part of this segment. If the special |
| 602 | attribute \f(CW\*(C`uninitialized\*(C'\fR is used (see below), then end_va may be |
| 603 | specified past the end of the segment. The \f(CW\*(C`uninitialized\*(C'\fR attribute |
| 604 | implies \f(CW\*(C`tsbonly\*(C'\fR (i.e., data is written to the \s-1TSB\s0 but not to the |
| 605 | memory image). |
| 606 | .IP "\fIdefault\fR" 4 |
| 607 | .IX Item "default" |
| 608 | If neither end_label nor end_va are specified, then the attr block |
| 609 | lasts until the end of the section. |
| 610 | .PP |
| 611 | \fIPhysical address\fR |
| 612 | .IX Subsection "Physical address" |
| 613 | .PP |
| 614 | An attr block must have one of the following keys to define the |
| 615 | physical address. The physical address is used to write \fImem.image\fR |
| 616 | .IP "\s-1PA\s0" 4 |
| 617 | .IX Item "PA" |
| 618 | The physical address is specified with the tag \*(L"\s-1PA\s0\*(R". It should be set |
| 619 | to an address, and the subset of the segment will be written to the |
| 620 | \&\fImem.image\fR file at that physical address. It is an error to write |
| 621 | to the same physical address twice in the same diag. |
| 622 | .IP "tsbonly" 4 |
| 623 | .IX Item "tsbonly" |
| 624 | This special key tells the attr block not to write anything to |
| 625 | \&\fImem.image\fR. It can be used if you want to create \s-1TSB\s0 entries but do |
| 626 | not want to overwrite something to \fImem.image\fR. If the key \*(L"\s-1PA\s0\*(R" is |
| 627 | included, it is used only for symbol table generation. |
| 628 | .IP "uninitialized" 4 |
| 629 | .IX Item "uninitialized" |
| 630 | This is exactly the same as tsbonly, except that normally the \*(L"end_va\*(R" |
| 631 | key is checked to make sure that it is contained in the segment. |
| 632 | Using uninitialized instead of tsbonly suspends that check. |
| 633 | .ie n .IP "hypervisor (or bypass on ""ultra2"" \s-1MMU\s0)" 4 |
| 634 | .el .IP "hypervisor (or bypass on ``ultra2'' \s-1MMU\s0)" 4 |
| 635 | .IX Item "hypervisor (or bypass on ultra2 MMU)" |
| 636 | The special tag \*(L"hypervisor\*(R" tells the attr block bypass both \s-1VA\s0 to \s-1RA\s0 |
| 637 | translation and \s-1RA\s0 to \s-1PA\s0 tranlation. The segment will be completely |
| 638 | unmapped. Therefore, it will not generate any \s-1TSB\s0 mappings, and it |
| 639 | will write to \fImem.image\fR at PA=VA (actually, it generates a \s-1PA\s0 from |
| 640 | as many low bits of the \s-1VA\s0 as will fit in a \s-1PA\s0). It is used for |
| 641 | segments where the \s-1MMU\s0 is off. For mmus that have only one level of |
| 642 | address translation (i.e., \*(L"ultra2\*(R"), the key \*(L"hypervisor\*(R" does not |
| 643 | exist, but \*(L"bypass\*(R" has the same meaning. |
| 644 | .IP "compressimage" 4 |
| 645 | .IX Item "compressimage" |
| 646 | This does not control the address, but it does affect how \fImem.image\fR |
| 647 | creation is done. If compressimage is given in an attr block then |
| 648 | lines of zeros are suppressed in \fImem.image\fR generation. Each |
| 649 | aligned 32\-byte chunk is compared against 0. If all bits are 0, then |
| 650 | it is not written to mem.image. If the global \-env_zero switch is |
| 651 | enabled (on by default in Niagara\-1), then a backdoor mechanism is |
| 652 | used to initialize the memory to zero in the environment. Otherwise, |
| 653 | it is left uninitialized. If the environment does not intialize all |
| 654 | memory to zero, then this can actually change the meaning of |
| 655 | mem.image, since it makes zero-ed memory uninitialized, rather than |
| 656 | intialized to zero. If the flag \-nocompress_image is given to |
| 657 | \&\fBmidas\fR, then no blocks are compressed, regardless of compressimage |
| 658 | tags. |
| 659 | .Sp |
| 660 | \fI\s-1TSB\s0 parameters\fR |
| 661 | .IX Subsection "TSB parameters" |
| 662 | .Sp |
| 663 | The following parameters should be set in each attr block (unless it |
| 664 | contains the \*(L"hypervisor\*(R" key described above, or the \*(L"bypass\*(R" key for |
| 665 | \&\*(L"ultra2\*(R"): |
| 666 | .RS 4 |
| 667 | .IP "\s-1RA\s0" 4 |
| 668 | .IX Item "RA" |
| 669 | This defines the real address (middle of the 3\-address scheme). It is |
| 670 | the address to be written to the \s-1TSB\s0 data. It must be page\-aligned. |
| 671 | In the \*(L"ultra2\*(R" \s-1MMU\s0, there is no \s-1RA\s0, so the \s-1PA\s0 gets double\-duty: \s-1PA\s0 is |
| 672 | used both for mem.image generation and for \s-1TSB\s0 data. |
| 673 | .IP "bypass" 4 |
| 674 | .IX Item "bypass" |
| 675 | This directive means to bypass \s-1VA\s0 to \s-1RA\s0 translation. In an \s-1MMU\s0 with |
| 676 | two levels of address translation (like niagara), it simply sets RA=VA |
| 677 | (actually, as many low bits of \s-1VA\s0 as will fit). It is an error to |
| 678 | specify both \s-1RA\s0 and bypass. In an \s-1MMU\s0 with one level of translation |
| 679 | (\*(L"ultra2\*(R"), it means to bypass all address translation, so its |
| 680 | function is similar to the hypervisor directive described above. |
| 681 | .IP "<tsb_name>" 4 |
| 682 | .IX Item "<tsb_name>" |
| 683 | Any tsb names that are listed (and there may be more than one) will |
| 684 | cause the attr block to add the subset to those TSBs. The tsb_names |
| 685 | must be defined somewhere in the diag with a \s-1MIDAS_TSB\s0 directive. |
| 686 | .IP "notsb" 4 |
| 687 | .IX Item "notsb" |
| 688 | Tells the attr block not to do any \s-1TSB\s0 generation. If \s-1RA\s0 is provided, |
| 689 | it is simply used in the symbol table. |
| 690 | .RE |
| 691 | .RS 4 |
| 692 | .Sp |
| 693 | Unless notsb is defined or the section is completely unmapped (bypass |
| 694 | for \*(L"ultra2\*(R" or hypervisor for other MMUs), the attr block will be |
| 695 | writing \s-1TSB\s0 entries. The following parameters are used to set the |
| 696 | appropriate bits of the \s-1TSB\s0 entry. How exactly the \s-1TSB\s0 entries are |
| 697 | formed is mmu\-specific. Check the \s-1PRM\s0 for your processor. The |
| 698 | default value for \s-1TTE_V\s0 (valid) is 1. The default value for all other |
| 699 | fields is 0. |
| 700 | .Sp |
| 701 | \fIMMU-Specific \s-1TTE\s0 Settings\fR |
| 702 | .IX Subsection "MMU-Specific TTE Settings" |
| 703 | .Sp |
| 704 | The fields in the \s-1TSB\s0 tag and data depend on the \s-1MMU\s0 type and the |
| 705 | currently configured ttefmt setting (sun4u or sun4v). The ttefmt is |
| 706 | can be contralled by the TSBs (which is always the case in Niagara\-2) |
| 707 | or by the global default set by \-ttefmt. The \s-1MMU\s0 specific settings |
| 708 | are described below. The default for each \s-1TTE\s0 setting is 0, except |
| 709 | for \s-1TTE_V\s0 (valid), which defaults to 1. All \s-1TTE\s0 tags are |
| 710 | case\-insensitive. |
| 711 | .Sp |
| 712 | Ultrasparc \s-1II\s0 \s-1MMU\s0 \*(L"ultra2\*(R" |
| 713 | .IX Subsection "Ultrasparc II MMU ultra2" |
| 714 | .Sp |
| 715 | The ultra2 \s-1MMU\s0 type supports only the sun4u \s-1TTE\s0 data format. |
| 716 | .IP "\s-1TTE_G\s0 Tag: 1 bit Global" 4 |
| 717 | .IX Item "TTE_G Tag: 1 bit Global" |
| 718 | .PD 0 |
| 719 | .IP "TTE_Context Tag:13 bits Context" 4 |
| 720 | .IX Item "TTE_Context Tag:13 bits Context" |
| 721 | .PD |
| 722 | %%TTE \s-1DATA\s0 ultra2 sun4u |
| 723 | .RE |
| 724 | .RS 4 |
| 725 | .Sp |
| 726 | Niagara \s-1MMU\s0 \*(L"niagara\*(R" |
| 727 | .IX Subsection "Niagara MMU niagara" |
| 728 | .Sp |
| 729 | The niagara \s-1MMU\s0 supports both the sun4u and sun4v \s-1TTE\s0 data formats. |
| 730 | .Sp |
| 731 | For sun4u, the following fields are valid: |
| 732 | .IP "TTE_Context Tag:13 bits Context" 4 |
| 733 | .IX Item "TTE_Context Tag:13 bits Context" |
| 734 | %%TTE \s-1DATA\s0 niagara sun4u |
| 735 | .RE |
| 736 | .RS 4 |
| 737 | .Sp |
| 738 | The following fields are valid for sun4v: |
| 739 | .IP "TTE_Context Tag:13 bits Context" 4 |
| 740 | .IX Item "TTE_Context Tag:13 bits Context" |
| 741 | %%TTE \s-1DATA\s0 niagara sun4v |
| 742 | .RE |
| 743 | .RS 4 |
| 744 | .Sp |
| 745 | Niagara2 \s-1MMU\s0 \*(L"niagara2\*(R" |
| 746 | .IX Subsection "Niagara2 MMU niagara2" |
| 747 | .Sp |
| 748 | The niagara2 \s-1MMU\s0 supports both the sun4u and sun4v \s-1TTE\s0 data format. |
| 749 | .Sp |
| 750 | For sun4u, the following fields are valid: |
| 751 | .IP "TTE_Context Tag:13 bits Context" 4 |
| 752 | .IX Item "TTE_Context Tag:13 bits Context" |
| 753 | %%TTE \s-1DATA\s0 niagara2 sun4u |
| 754 | .RE |
| 755 | .RS 4 |
| 756 | .Sp |
| 757 | The following fields are valid for sun4v: |
| 758 | .IP "TTE_Context Tag:13 bits Context" 4 |
| 759 | .IX Item "TTE_Context Tag:13 bits Context" |
| 760 | %%TTE \s-1DATA\s0 niagara2 sun4v |
| 761 | .RE |
| 762 | .RS 4 |
| 763 | .IP "TTE_Context Tag:13 bits Context" 4 |
| 764 | .IX Item "TTE_Context Tag:13 bits Context" |
| 765 | %%TTE \s-1DATA\s0 sun4v |
| 766 | .RE |
| 767 | .RS 4 |
| 768 | .Sp |
| 769 | There are a few special cases to be aware of: |
| 770 | .IP "TTE_Size" 4 |
| 771 | .IX Item "TTE_Size" |
| 772 | This is the size bits field to use in the \s-1TSB\s0 entry. It is also used |
| 773 | to calculate the number of pages the attr block will create. The attr |
| 774 | block will create as many pages as it needs to to span the section. |
| 775 | The TTE_Size field controls the size of these pages. See the \s-1PRM\s0 for |
| 776 | the exact coding of page size in TTE_Size. For Niagara, Niagara\-2, |
| 777 | the encoding is: |
| 778 | .RS 4 |
| 779 | .IP "0 \-> 8 kB" 4 |
| 780 | .IX Item "0 -> 8 kB" |
| 781 | .PD 0 |
| 782 | .IP "1 \-> 64 kB" 4 |
| 783 | .IX Item "1 -> 64 kB" |
| 784 | .IP "2 \-> 512 kB (illegal on Niagara and Niagara\-2)" 4 |
| 785 | .IX Item "2 -> 512 kB (illegal on Niagara and Niagara-2)" |
| 786 | .IP "3 \-> 4 \s-1MB\s0" 4 |
| 787 | .IX Item "3 -> 4 MB" |
| 788 | .IP "5 \-> 256 \s-1MB\s0" 4 |
| 789 | .IX Item "5 -> 256 MB" |
| 790 | .IP "6 \-> 2 \s-1GB\s0 (illegal on Niagara and Niagara\-2)" 4 |
| 791 | .IX Item "6 -> 2 GB (illegal on Niagara and Niagara-2)" |
| 792 | .IP "7 \-> 16 \s-1GB\s0 (illegal on Niagara and Niagara\-2)" 4 |
| 793 | .IX Item "7 -> 16 GB (illegal on Niagara and Niagara-2)" |
| 794 | .RE |
| 795 | .RS 4 |
| 796 | .PD |
| 797 | .Sp |
| 798 | The \*(L"ultra2\*(R" \s-1MMU\s0 only has a 2\-bit size field, so it supports page |
| 799 | sizes 0\-3 (which are also 8 kB \- 4 \s-1MB\s0). |
| 800 | .Sp |
| 801 | Note that when the above sections state that \s-1VA\s0, \s-1RA\s0, and \s-1PA\s0 must be |
| 802 | page-aligned when adding them to a \s-1TSB\s0, this is where the page size |
| 803 | comes from. |
| 804 | .RE |
| 805 | .IP "TTE_Size_Ptr" 4 |
| 806 | .IX Item "TTE_Size_Ptr" |
| 807 | The page size is used in the formula to calculate a \s-1TSB\s0 pointer. The |
| 808 | page size used for pointer calculation is controlled by a hardware |
| 809 | register, but \fBmidas\fR needs to set up the TSBs statically. By |
| 810 | default, the attr block with use TTE_Size when it computes the \s-1TSB\s0 |
| 811 | index (or the \s-1TSB\s0 page_size parameter/Niagara\-2 \s-1TSB\s0 config, if one is |
| 812 | defined), as well as for the uses above. If you set TTE_Size_Ptr, |
| 813 | however, it will use this as the page size setting when computing the |
| 814 | \&\s-1TSB\s0 index. Use this whenever you wish to have a different setting for |
| 815 | TTE_Size than the hardware will have in its config register. |
| 816 | .RE |
| 817 | .RS 4 |
| 818 | .Sh "High Level Languages" |
| 819 | .IX Subsection "High Level Languages" |
| 820 | The output of compilers of high-level languages may be inserted into midas. |
| 821 | .Sp |
| 822 | \fIObject files\fR |
| 823 | .IX Subsection "Object files" |
| 824 | .Sp |
| 825 | The midas directive: |
| 826 | .Sp |
| 827 | .Vb 1 |
| 828 | \& MIDAS_OBJ FILE=<something.o> |
| 829 | .Ve |
| 830 | .Sp |
| 831 | may be placed inside any section. That object file will be linked |
| 832 | with the assembly output for the section and will share its attr |
| 833 | blocks. No special interpretation is done on the contents of the |
| 834 | object file \- the text, data, and bss segments are simply linked in |
| 835 | with the output of the assembler for that section. The search path |
| 836 | for .o files is controlled by the \-L switch. The default path is the |
| 837 | starting directory, and <diag_root>/verif/diag. |
| 838 | .Sp |
| 839 | \fILibrary files\fR |
| 840 | .IX Subsection "Library files" |
| 841 | .Sp |
| 842 | The midas directive: |
| 843 | .Sp |
| 844 | .Vb 1 |
| 845 | \& MIDAS_LIB FILE=<something.a> |
| 846 | .Ve |
| 847 | .Sp |
| 848 | Works just like a \s-1MIDAS_OBJ\s0 directive, except that it includes a |
| 849 | library in the link. Note that the library must be static (i.e., a .a |
| 850 | file, and not a .so file), because there is no runtime linker in the |
| 851 | diag environment. Other than the file format, the difference between |
| 852 | a library file and an object file, is that an object file will include |
| 853 | all text/data/bss from the file, but linking with a library file will |
| 854 | cause only those symbols that are actually used to be included. |
| 855 | .Sp |
| 856 | Library files will also search the same link path as object files. |
| 857 | .Sp |
| 858 | \fIC files\fR |
| 859 | .IX Subsection "C files" |
| 860 | .Sp |
| 861 | Simiar to object files, C language files may be included with the |
| 862 | directive: |
| 863 | .Sp |
| 864 | .Vb 1 |
| 865 | \& MIDAS_CC FILE=<something.c> [OUTPUT=<something.o>] [ARGS=-O2] |
| 866 | .Ve |
| 867 | .Sp |
| 868 | The \s-1OUTPUT\s0 and \s-1ARGS\s0 tags are optional, but the \s-1FILE\s0 tag is mandatory. |
| 869 | The search path for the C source file is controleld by the \-C switch, |
| 870 | and the default is the starting directory, then |
| 871 | <diag_root>/verif/diag/c. The \s-1ARGS\s0 tag (which must appear |
| 872 | last, since the args last until the end of the line) is arguments to |
| 873 | gcc. You must not use the \-o or \-c switches, since midas will provide |
| 874 | its own. If \*(L"\-S\*(R" is supplied to gcc through the \s-1ARGS\s0 tag, then gcc \-S |
| 875 | will be used to create an assembly file in the Sectioning phase, which |
| 876 | will then be assembled like all the other assembly files in the |
| 877 | Assembly phase. If \-S is not present, then nothing is done in the |
| 878 | Sectioning phase (except for finding the C file and copying it to the |
| 879 | build directory). Rather, gcc is used to compile the C file directly |
| 880 | to an object file during the assembly phase. The object file, |
| 881 | generated either by gcc or by the of assembling of gcc \-S, is then |
| 882 | linked in with the rest of the section. Once the object file is |
| 883 | generated, it is treated just as a \s-1MIDAS_OBJ\s0 directive. |
| 884 | .Sp |
| 885 | Stack |
| 886 | .IX Subsection "Stack" |
| 887 | .Sp |
| 888 | Compiled C code expects the system to set up a stack for it before it |
| 889 | runs. Template files are provided for this purpose. Be sure to use |
| 890 | them or have some solution for setting up the stack if you are working |
| 891 | with compiled code. |
| 892 | .SH "AUTHOR" |
| 893 | .IX Header "AUTHOR" |
| 894 | .SH "SEE ALSO" |
| 895 | .IX Header "SEE ALSO" |
| 896 | \&\fBmidas\fR(1), tre_perldoc Midas, \fBpal\fR(1), \fBgoldfinger\fR(1). |