List File format for comment
BradC
Posts: 2,601
G'day all,
Cluso99 was talking about list files with address absolute rather than Object based, so before I go much further I thought I'd put this up for comment.
It still has the odd bug relative to display of PBASE absolute address variables, and no disassembly of the DAT sections yet (but they are coming).
It's a full compilation of FemtoBasic, so it's not small.
Comments are most welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Cluso99 was talking about list files with address absolute rather than Object based, so before I go much further I thought I'd put this up for comment.
It still has the odd bug relative to display of PBASE absolute address variables, and no disassembly of the DAT sections yet (but they are coming).
It's a full compilation of FemtoBasic, so it's not small.
Comments are most welcome.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
txt
576K
Comments
I don't know if I'm envious or inspired.
/should be inspired
//mostly envious
///shakes tiny fist at Brad
As long as I/we can get to the absolute hub address (and pasm cog address) near the left side and the extra lines can be easily distinguished, then this is ideal to link to the debugger. This will allow dynamic display of the executing code.
I've figured that I can use the hub base address of pasm to determine the code from the listing, but obviously it will not work for overlays. Haven't thought about the LMM models.
If either of you want, you are welcome to the disassembler pieces of my pasm debugger. It is not complete (displays 'and' instead of 'test', etc) but it is in spin and using a lot of case statements. Not very efficient but it works. (see PASM and Spin Debugger with zero footprint posting today)
259 rowClr := c <# rows-1
:
Addr : 6DFF: E5 : Math Op <|
Top notch! that was an error in my disassembler symbol list I'd never noticed. Thanks [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Mixed assembler and spin bytecode? Not quite sure I understand.
I've not got around to implementing the assembler list output yet (busy with the ide).
The Assembler listing is a whole lot easier to get right than the spin list though..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
So are you going for an IDE ?, would be great then to integrate GEAR (it is also in C#) into it for fast testing of code.
Yes, with the compiler built in.. basically a bit of a knockoff of proptool, but for linux/bsd/mac/windows98 also..
Just a bit of fun to keep me amused. (Actually, I want to have the features of proptool and not have to boot a VM with Windows to do it)
Yeah, except gear is in C#.. and I'm not using .Net or Java, it's all native ObjectPascal.
I can't see why scripted plugins of some sort can't be called as a sub-process though.. Just like I'm looking at providing pre-processor hooks..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
would it be possible for your Spin compiler to interoperate with PASM and PLink somehow? Perhaps you could implement POFF output (preferable!) or at least linking of it into Spin code?
The current POFF format is at tdn.teknetium.com/project/proptools/browser/trunk/poff/poff.h, but I'm planning on enhancing it; in particular, adding better debugging support and adding more power to relocations (For example, the ability to do A * 2 +
I'm positive that some form of interoperation is possible.
I'm not sure how POFF fits into the picture as currently my output is bit for bit identical to the Parallax .binary and .eeprom formats. Relocating SPIN is not terribly difficult provided you fix up the object table correctly. I've had a brief look at that link, but I'm obviously too hung over to see what I could bring to the table with that.
Ideally I'd like to see the IDE support VMM and LMM development natively, which would mean incorporating some aspects of VMM/LMM assembler into my current compiler.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
One thought I had was that, somehow, you could add external symbol support to Spin? As for intergrating with the IDE, could you not just call PASM?
I can't see any major issues with external symbol support.. just have to have a good think about how to integrate it in.
I don't have a problem calling external software, provided the author supports it across several platforms (at a minimum, linux 386/x86_64, MacOS PPC and Intel and Windows 98+). So it must be endian clean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
Nope, it's mpark who has the compiler in C#.
I'd not abandon anything, more tools are better than less [noparse]:)[/noparse] (Unless you don't really want to work on it anymore).
I write most of my PC based stuff in ObjectPascal as I've been using it for years and it lets me be compact and cross platform.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!
The beginnings of endian support are there, I just need to add it everywhere. As for OS X support, it should work on OS X (x86 only at the moment), but I don't have access to an OS X box to test it. Anyone with C++ and OS X experience is of course free to become the OS X maintainer if they wish.
Don't know.. kinda busy enough with the cross platform compiler/loader and Unicode compatible IDE at the moment [noparse]:)[/noparse]
I guess if I ever develop a need for a simulator I might look at it. I've got Gear and I think I've used it once.. so it's not high on my list right now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pull my finger!