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.
You seem to have CSS turned off.
Please don't fill out this field.
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
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.
I am referring to the NitrOS-9 Technical Reference:
$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?
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 :-)
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 https://sourceforge.net/apps/mediawiki/nitros9/index.php?title=Memory_Modules it looks like modules of Type $1x-$Bx (and Language $x1) should have a valid execution offset of the kind I am looking for.
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.
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?
Objct equ 7
Objct equ 1
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.