device descriptors flagged as object code

  • Tormod Volden

    Tormod Volden - 2014-02-02

    Device descriptors such as "DD" currently have the type/language $F1 which defines the language as "6809 object code". Although OS9 also does this, shouldn't they be $F0 "Data (non executable)"?

    Just noticed since I've made a MDIR script for gdb which prints out the execution address for executable modules.

    Last edit: Tormod Volden 2014-02-08
  • Robert Gault

    Robert Gault - 2014-02-02

    That's not quite right. When you do an Ident on DD, you will get
    Ty/LA At/Rv $F1 $81
    Look at the os9.d file and you will see

    Module Type/Language Field Masks
    TypeMask EQU %11110000 Type Field
    LangMask EQU %00001111 Language Field

    Module Attributes / Revision byte

    Field Masks
    AttrMask EQU %11110000 Attributes Field
    RevsMask EQU %00001111 Revision Level Field

    So, the type is Device Descriptor $F0, the language is 6809 object $01, and the attribute is re-entrant. A descriptor is not a data module but if it were that would be $41 not $F0. It is re-entrant which is indirectly related to being executable.
    Modules/files are either executable or not when they exit on a disk. This parameter does not exist as such for a module in memory.

  • Tormod Volden

    Tormod Volden - 2014-02-08

    I am referring to the NitrOS-9 Technical Reference:
    Code Language
    $x0 Data (non executable)
    $x1 6809 object code

    I am not disputing the module type $Fx (device descriptor module), but the "language". Is it object code? It is definitely not executable code.

    How can I tell if a module has an executable entry point or not?

  • Bill Pierce

    Bill Pierce - 2014-05-26

    Tormod, sorry the answer to this is late, but better late than never...
    As Robert was describing, the info you need is in the header, but things got confused and you didn't make your real point until the last message.

    To find out if a module is executable, just check the attr/revs byte in the header as he said. The first four (high) bits contain:
    bit 7 - Re-Entrant module
    bit 6 - Module protect bit
    bit 5 - Native 6309 module

    Now you need to combine the info in these bits with the Typ (type/lang) bits described above, which are:
    0001xxxx - Program module (exec)
    0010xxxx - Sub-routine module (exec)
    0011xxxx - Multi module (??)
    0100xxxx - Data module (no exec)
    0101xxxx - Shell sub-module (exec)
    0110xxx - 1011xxxx - undefined
    1100xxxx - System module (exec)
    1101xxxx - File manager (exec)
    1110xxxx - Device driver (exec)
    1111xxxx - Device descriptor (no exec)

    Now I know this really doesn't answer your question and just rehashes what Robert was explaining, but once a file is in memory, this is all you have. The fact of whether a file is an executable was determined by OS9 when the file was loaded from disk, not after it's in memory. That info is in the "file descriptor" pointed to by the last 3 bytes of the 32 byte directory entry on the disk.
    This 24 bit offset points to the file descriptor block in which the very first byte of that block is the attribute byte.
    When a file is loadeded, this byte is checked for it's attributes/permissions and therefore, OS9 knows if it can be exec'ed and once loaded, OS9 will set up space require etc, and jump to it's starting address or if the language is not Object, OS9 will attempt to load the proper run-time module for that coe (ie. basic09's "runb" etc)
    So the only real way I know to check if a file can be exec'ed is to check it on disk. The attribute byte in the file descriptor is the same byte the "attr" utility checks when it is run. The result is the 8 bit flag for the files attributes....

    bit 7 - Directory flag, set file is a directory
    bit 6 - Sharing flag, set the file is non-sharable
    bit 5 - Read flag, set is "owner" read permission
    bit 4 - Write flag, set is "owner" writable
    bit 3 - Exec flag, set is "owner" extutable
    bit 2 - Public Read flag, set is public readable
    bit 1 - Public Write flag, set is public readable
    bit 0 - Public Exec flag, set is public exectuable

    So, as you see, once a file is in memory, it was already determined if it could be exe'd and all OS9 needs to know from there is that if it is called again, can it by re-entered and run in another instance? That's where the above attr/revs byte in the header comes in as well as the typ/lang byte. It's really a combo of all of the above.

    The confusion you were having was in the "lang" which on describes the format the file is "written" in. 6809 Object and 6309 Object just describes the file as written in OS9 assembly. The other "languages" supported are Basic09 I Code, Pascal P code, Fortrain code, Cobal Code, and C Code (not used in Coco OS9 as C is compiled to Object code)

    I hope some of this makes sense :-)

  • Tormod Volden

    Tormod Volden - 2014-06-08

    Thanks Bill. I still feel that device descriptors should have been of code language "data" and not "6809 object code", but I guess it is too late to change that!

    I do not agree that "lang" says what the file is written in, rather it says how the bytes should be interpreted. 6809/6309 objects (if they are meant to run) run natively on the processor, the others need a byte interpreter of some sort. Whether the 6809 object is written in OS9 assembly or typed in a hex editor is not relevant :)

    Now back to my practical problem: I want to parse the in-memory module directory and extract the entry point for executable 6809/6309 (as in running directly on the CPU) modules. If I now understand correctly I must filter this out from the Type field and not only the Lang field. I understand that the OS9 notion of "executable" here is not what I generally put into it.

    From the "Module Headers: Type-Dependent Information" section of it looks like modules of Type $1x-$Bx (and Language $x1) should have a valid execution offset of the kind I am looking for.

  • Bill Pierce

    Bill Pierce - 2014-06-08

    Tormod, the whole "6809 object code" scenario could be summed up in ignoring that description and looking at the others. The "Basic09 I-Code", "Pascal P-Code", etc..
    Without a "language" flag, OS9 would not know what "pre-processors" to run for the code.
    Since most of the others do need a preprocessor, "6809 object code" does not.
    I would agree that the "6809 object code" description is a little deceiving.

    But to your problem...
    Here's a rundown:
    $1x - $3x = executable
    $4x = non-executable: That's a data module and is just.... data
    $5x - $Bx = User defined modules, for the most part could be considered non-executable. Usually used for propriety data files (Dyna-Star, Desk Mate etc... who knows?) OS9 does not know what these modules are, so I doubt OS9 would even attempt to execute them.
    $Cx - $Ex = executable, all are forms of "system" modules, usually (but not always) in the bootfile. (some can be loaded later).
    $Fx = non-executable, usually descriptor modules for $Dx-$Ex above

    $1x, $2x, $3x, $Cx, $Dx, & $Ex would be the only modules that would have an exec offset.
    And yes, they would most likely be "lang" $x1, as the others would involve preprocessors.

    Also, according to the "os9.d" defs file, more have been added to the list since the printing of the wikki.

    Objct EQU 1 6809 Object Code Module
    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
    Obj6309 EQU 7 6309 object code

    Devic EQU $F0 Device Descriptor Module
    Drivr EQU $E0 Physical Device Driver
    FlMgr EQU $D0 File Manager
    Systm EQU $C0 System Module
    ShellSub EQU $50 Shell+ shell sub module
    Data EQU $40 Data Module
    Multi EQU $30 Multi-Module
    Sbrtn EQU $20 Subroutine Module
    Prgrm EQU $10 Program Module

    With these new additions, lang $x7 could possibly be executable as well. Though it's not been properly placed in any of the repo sources, it's "supposed" to signify having been assembled/compiled in 6309 asm. This is needed to help identify 6309/6809 files when building boots and/or copying files to a disk. And we know inserting a 6309 file in a 6809 system doesn't ever end well... or shall we say NEVER ends well... This needs to be done to all 6309 flagged files in the repo. As it is now, there's no way of knowing if a file is 6809 or 6309, unless you built the repo yourself and pulled it from the proper dir.

  • Tormod Volden

    Tormod Volden - 2014-06-08

    Thanks again, Bill! It is getting clearer to me.

    For the 6309 flagging, what if we just set Objct to 7 if we are compiling for 6309 and make sure all module headers use Objct?

    ifne H6309
    Objct equ 7
    Objct equ 1

  • Bill Pierce

    Bill Pierce - 2014-06-08

    Tormod, that is exactly what the obj6309 was implemented for. I guess in all the switching of build environments, it was forgottenas that was about when it was introduced as well. I have built several bootfiles only to have them crash, then figure out later I was using the wrong files. I use 6309 in Vcc and 6809 on my real Coco 1, 2, & 3, so it get's confusing when there's no way to tell the difference. As it is now, they all say 6809 object.



Cancel  Add attachments