Omnimaga
Calculator Community => TI Calculators => Calculator C => Topic started by: SirCmpwn on January 09, 2011, 01:37:43 pm
-
Hello,
At what offset does a Ndless program contain executable code?
-
The startup code is currently just after the signature 'PRG\0' i.e. at offset 4.
But note that this is not part of any standard and is subject to change if features are added to the tool chain and the program loader. Tell me if you need any stable convention.
-
Does this have anything to do with being ARM6 or ARM9?
-
Not at all, this is a choice specific to Ndless.
-
I would like a nice convention, if possible. Also, is the code location-independent?
I would suggest, for a standard:
PRG\Header
Header\Desc
Null-terminated description
Header\Ico
32x32 Icon
PRG\Exec
Executable Code
This leaves a lot of room for extra stuff to be added later, like more Header\Stuff
-
Ok, so you'd like information for shells.
If the program format was to change, I would prefer to move towards a standard format such as BFLT or ELF, but I don't how this meta-data could be integrated to such formats.
-
I'm not sure how easily an existing standard could move over, but I think I have a good idea for a file format:
[ASCII] PRG\0 // Compatibility
[Asm] B CodeStart // Compatibility
[ASCII] STDNDLESS // Used to identify that the Ndless Standard is being used
[Headers] [Header data] // Metadata
[ASCII] M_END // End of metadata
[Asm] .CodeStart // Label to jump to
[Raw Data] [Executable] // Actual program contents
The format for headers would be as follows:
[ASCII] H_START // Signifies the start of a header
[ASCII] [Header Name] // Used to identify which header this is (null terminated)
[Raw Data] [Header data] // The actual header data
These would be the required Ndless headers (required if following this format, not if otherwise):
Name: NDLESS_M_VER
Description: The minimum required version of Ndless
Data: ASCII representation of the version number (ex. "1.7")
Name: NDLESS_T_VER
Description: The target version of Ndless. (The one that this file was built with)
Data: ASCII representation of the version number (ex. "1.7")
Name: SUPPORTED_HW
Description: All versions of the TI-Nspire supported
Data: Null-terminated list of supported hardware versions
Hardware Versions:
0x01: TI-Nspire Clickpad
0x02: TI-Nspire Clickpad CAS
0x03: TI-Nspire Touchpad
0x04: TI-Nspire Touchpad CAS
The remaining headers would be ignored by Ndless, and optional. They could be used for shells and such to identify programs and retrive more information about them. This format could also be executed the same way as the current format without any issues. Of course, Ndless should check the required fields. In addition, because of the way that it would be executed (start at "B CodeStart"), even if the metadata is corrupted, it would still be able to execute the program without trouble, as well as allow the metadata to include special strings such as "M_END" without crashing the calcualtor from executing metadata. It is also very extensible to a variety of situations, and allows for backwards compatability throughout the development of Ndless. It also allows an easy way to add features (again keeping compatability) and have safety checks for incompatible OS versions.
-
That looks a lot like headers from Z80-series programs. Unfortunately, that is not very flexible. I would suggest the following instead:
struct header {
char[8] "NdlessEx"; // Identifies program as Ndless executable
void (*main)(); // Pointer to main entry point, or 0 if no basic main entry point is specified
void *relocationData; // Pointer to relocation data block, or 0 if no relocation data is present
void *metadata; // Pointer to meta-data block, or 0 if no meta-data is present
void *debugSymbols; // Pointer to table of debugging information, or 0 if no debugging information is present
int 0; // Specifies that no additional pointers are present in the header block
};Following the header block, no particular structure is imposed on the file. The main function, meta-data, debugging symbols, and relocation data can be placed anywhere in the file and in any order. There is no requirement for any of these blocks to be located immediately after the header block; programs can have functions or data after the header block if desired. Future standards may replace the 0 integer after the final pointer with additional pointers as needed.
To run a program, the Ndless loader will first examine the meta-data in the file, if present and necessary by future standards. Ndless will then process the relocation table, if present. Finally, Ndless will jump to the main entry point.
The main pointer may be null if the program has no main entry point. This could be because the program is actually a library, in which case Ndless may still need to perform relocation, and the library can present its metadata and debugging data in a standard format. This may also be because the program is not a raw Ndless executable, but based on the standard because, for example, it adheres to a later standard and should not be run by earlier Ndless versions, or is a shell-only program, in which case the shell will find the main entry point in a implementation-specific way (while still taking advantage of Ndless's future native relocation, meta-data, and debugging abilities.)
The format of the relocation data structure is not specified here. Somebody with more experience in that area may wish to define that.
The meta-data block should be XML-encoded using the encoding the Nspire prefers. The XML data block may be parsed using TI's routines. This data may be presented to the user by a shell. Programs may choose to read their own meta-data to, for example, display their own version information. Programs should include, at a minimum, Version, Title, and Author tags. Additional Author tags may be present for group projects. Additional tags may include Date, Description, Icon, and Copyright. The meta-data block is also a good place to place information on additional libraries needed, and minimum hardware, operating system, and/or Ndless version requirements.
The format of the debugging data structure is not specified here. This may become a part of the Ndless standard; or, the standard may simply state that debugging data is specific to a particular combination of compiler/linker and debugger, whether in-system or via emulator.
-
I'm not sure using a 0 word to mark the end of the structure would work, because any of the earlier words can also be 0.
-
How about length prefaced?
-
It's not so much an end marker as a version number, I guess.
-
Version number should go first, I'd think.
-
Fine, put a version (d)word at the start. Ultimately, it's not up to me.
-
Or just use the ELF format. Tools already exist for it. Ndless would just need support for reading it.
-
(just found this topic now)
Should we settle for a custom format, I also think that the version number should be first.
A standard was defined long ago for TI-68k AMS native programs and is supported by TIGCC/GCC4TI, but it hardly got implemented by file explorers.
-
Thank you all for your suggestions.
It appears to be a significant amount of implementation work and maintenance just for a better experience with possible shells and file explorers, and unfortunately cannot be one of my current priorities. Hopefully this may change once the current major missing features of Ndless are implemented, or if other interesting use cases are identified.