Assembler and standards

[bholroyd]

Hi.

You've inspired me to write an assembler to hopefully get running on pshell. I was also going to do a preprocessor as your C (PC?) only has basic support.

in the interests of skating to where the puck is going to be what are your plans re linking libraries, executable formats, process management, etc?

I note youve already implemented a run command and a file format.

I guess this describes the file header

struct exe_s {
int entry;
int tsize;
int dsize;
int nreloc;
};

is this somewhat stable?

I assume entry is main() tsize is the size of the text section and dsize is the size of the data section? I'm having trouble working out what nreloc does though. I assume executables start with the "exe" magic number? although I can't find reference to it being added in the cc source, only being used in main.c.

[lurk101]

Lots to unpack in those questions!

Stable? I doubt it! This is a personal project to explore to what extent a reasonably competent environment can be built on a modern embedded SoC. As such, backward compatibility is not a priority concern and changes will be made freely.

You speak of libraries and that implies some kind of linker function and code relocation. The executable produced by the pshell compiler are not truly relocatable, they are compiled to, and run at, fixed code and data segment addresses. You correctly note that tsize and size are the section sizes. entry is the entry point address. The nreloc value gives the number of addresses that need to be relocated. This list is appended after the text and data section. Why is a relocation list required if everything runs at fixed addresses? It is necessary since the Pico SDK functions the executable relies on exist in the pshell code and can move if pshell is recompiled.

The "exe" magic number is not stored in the file data. It is stored as a file attribute.

A 'real' pre-processor enhancement would be a big improvement.

[bholroyd]

You speak of libraries and that implies some kind of linker function and code relocation

Slightly joking here :-P although I was mulling it over and all you need is the address of a function jump to it, jump back. I suppose doing it 'correctly' you'd have a jump table, but that doesn't seem particularly onerous.
to clarify I was thinking in terms of exposing OS type things like system calls, (open, close, print, exit) rather than libraries per se. this could also make the nreloc variable moot.

The executable produced by the pshell compiler are not truly relocatable

Is there not a PC relative subset thats usable?
You're right though I hadn't considered that. I've been spoilt with OSes giving me nice things!

A 'real' pre-processor enhancement would be a big improvement.

Yes. well i'm doing one for an assembler so I thought I may aswell split it out so it can be shared. 'real' may be pushing it a bit though lol.

[lurk101]

Lots to unpack in those questions! Stable? I doubt it! This is a personal project to explore to what extent a reasonably competent environment can in built on a modern embedded SoC. As such, backward compatibility is not a priority concern and changes will be made freely. You speak of libraries and that implies some kind of linker function and code relocation. The executable produced by the pshell compiler are not truly relocatable, they are compiled to, and run at, fixed code and data segment addresses. You correctly note that tsize and size are the section sizes. The nreloc value gives the number of addresses that need to be relocated. This list is appended after the text and data section. Why is a relocation list required if everything runs at fixed addresses? It is necessary since the Pico SDK functions the executable relies on exist in the pshell code and can move if pshell is recompiled.

…

On Mon, Aug 22, 2022 at 3:12 PM bholroyd ***@***.***> wrote: Hi. You've inspired me to write an assembler to hopefully get running on pshell. I was also going to do a preprocessor as your C (PC?) only has basic support. in the interests of skating to where the puck is going to be what are your plans re linking libraries, executable formats, process management, etc? I note youve already implemented a run command and a file format. I guess this describes the file header struct exe_s { int entry; int tsize; int dsize; int nreloc; }; is this somewhat stable? I assume entry is main() tsize is the size of the text section and dsize is the size of the data section? I'm having trouble working out what nreloc does though. I assume executables start with the "exe" magic number? although I can't find reference to it being added in the cc source, only being used in main.c. — Reply to this email directly, view it on GitHub <#13>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQBPNGHOFK3UZUJKXWIUSCTV2PGLFANCNFSM57IZD2PA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>