I'm unaware of any GCC builds that support z80 code generation, which, iirc, is why AHelper uses SDCC.

I still think it would be a good idea to write a z80 LLVM backend, and make use of Clang. It would be interesting to profile possible performance improvements in GlassOS between the two compilers if that were done.

Thanks! And yes, glassLink is an interface to the many USB services used by the calc. Only USB, no I/O.

GCC doesn't support z80 compilation. According to the GCC project page, there was a z80 port of GCC done by a 3rd party, but no such project can be found (or, none that can run).

If you can get something started, I would be glad to chip-in wherever possible. I just have no idea on what llvm (a compiler, but what is so special with it?) is or how it works.

I could probably do the device specific stuff, but you would need to write the code for the linker, since I don't know anything about your binary formats or calling conventions.

LLVM isn't quite a compiler, but it forms part of a toolchain for producing compilers, virtual machines, and all sorts of other goodness. Many compilers exists that target the LLVM backend, but Clang is the most well known, as it is the C compiler used on modern Apple systems.

The steps for writing a compiler back-end for code generation using LLVM are outlined here: http://llvm.org/docs/WritingAnLLVMBackend.html

This talk might be helpful:



[edit]

Ooo. I just realized, with LLVM, it's quite easy to make a single C compiler that can compile with or without undocumented instructions, so that you can recompile for the Nspire's 84+ keypad, or the TI SDK emulator (if that still exists?).

[edit 2]
I just started work on machine definitions. I think I have the register layout specified, between looking through the Sparc and Mips examples, plus an abortive attempt at a similar project here: https://github.com/stev47/llvm-z80-testing

The next step is actually specifying the possible instruction formats, and their behaviors (and which ones are allowed for which platforms), which will be the real bear, and how various types should be handled. We probably want to mimic the SDCC calling and type conventions closely if you're using those and want to maintain compatibility, but I don't know a lot about them, since I haven't used SDCC. Shouldn't be too hard to allow it to emit either machine code or z80 assembly (though we'd have to choose which assembler to support. I like spasm, but I know many others prefer brass). I haven't yet delved into how linking should work, but it would be nice if we made a version that also supported DCS/TI-OS.

If this is going to be successful, firstly, can it pass arguments like the hitachi format (as registers unless they can't fit)? Secondly, this requires a topic. For now, here is fine until something starts to work. Anyways, this is the only project that really uses C for the z80 calcs.

We define the calling conventions for code generation, that's why I was asking for your input.

Let's split a new topic now, and try and get this on it's feet. The thing about having a z80 target for LLVM, is that pretty much *anything* can be compiled to it, not just C, because there are many many compilers and languages that use LLVM for compiling. And LLVM is supposed to have very good optimization, so I suspect that unless we really botch the z80 side specifically (register allocation), that we ought to get good performance. There is an option to write a machine code optimizing pass as well, so we could always try that later if we aren't satisfied.

Do you have a preference for source hosting? GitHub? SourceForge?

ok, good. I forked that project on github and will start working on it and seeing where it is at. If you want access to the repo, I can open that up to you.

oh, let me add the stuff I worked on today. If you could open it up to me that would be great.

Ok. For conventions, having registers passed as parameters is a MUST. This is a serious issue in SDCC. putchar(unsigned char x) pushing 1 byte (yes, push af \ inc sp) is stupid. And I am not the only to think that. I read the source of gen.c, the ASM generator in SDCC, and the author saw huge savings for parameters. He calculated over 55 bytes per parameter (assuming word) for overhead when using ix (stack based) rather than register arguments. Note, this should be configurable on a per-function basis.

Also, having inline functions working will help with stuff like bcalls (libexec in GlassOS)

More overkill but needed: IO ports and locating variables in memory. This is required for the z80 since you have parts of the memory allocated statically and you also need to access ports. SDCC allows this.

Just goals to be better than sdcc

The commit I'm sending up now updates us to llvm 3.1, instead of whatever old version was around 2 years ago, and moved in the files that I actually changed when I started using Sparc as a more developed example to work from. It shouldn't build in its current state, but we have the framework to work from. The next phase, I think, is filling in the rest of the TableGen data for the instruction formats and instruction behavior and all that good stuff. We should make sure the ability to use undocumented instructions is target dependent, which is illustrated nicely for us by the Sparc target (which has 64bit and 32bit subtargets).

Our base should be the PIC16 as it is a similar 8 bit CPU. This will be a good base, but yes, a SPARC base will also help in places that the PIC16 fails at.

Good point. I was just using SPARC initially, because it was the suggestion in the tutorial on the LLVM website (helpful link to keep around, btw).

On second thought, PIC16 is a bit messed up

I am looking for a good starting point still. PIC16 and MSP430 came up as they are also lower-level CPUs, but I lack knowledge on them :/

I think the next step is mostly just going to be filling in the information about the instruction set information Z80InstrFormat.td and Z80InstrInfo.td based on this: http://z80.info/ and the tutorial I just linked. I suspect the PIC targets will be useful when we need to start with the real implementation stuff.


-----
Notes for ahelper:


Code:

Committing modifications required to build the Z80 port in the standard way.

Doesn't compile due to 'Z80Subtarget.h:21:35: fatal error: Z80GenSubtargetInfo.inc: No such file or directory' but progress!

Keep in mind that synchronizing and committing are separate operations. You have to commit first, and then synchronize to send the changes back up.

The Z80GenSubtargetInfo.inc has to be the result of running TableGen on our .td files, if I understand correctly. I think Z80.td is the one that should control the Subtarget info, but I may not remember correctly. In either case, that's where to start looking!

So, git kinda derped. I committed my changes and pushed, but it pulled your changes in first, ok. Then it pushed. So, it has my changes, good. But it has a the branch merged into itself and shows your changes in it. Should I get rid of that as it did nothing...?

(stopped working on that for sleep)

Seems ok? I dunno.

https://github.com/AHelper/llvm-z80-target/commit/f72c71370e5c2bc650cc45a468305c3671cedfaf

Not really. I pulled in your changes to my local copy just to check for conflicts, but it ended up making another commit with all of your changes...

Hello,

I just noticed that you forked my old z80 codebase and am amazed that you are willing to work on the llvm backend.

Some quick notes:

Take a look at this project:
http://sourceforge.net/projects/llvmz80/
It seems to be active and might be a better starting point than my old codebase.

I can recommend the llvm-talk "Tutorial: Building backend in 24 hours":
http://www.llvm.org/devmtg/2009-10/
If I remember correctly there was a more recent talk on backend building (or rather a workshop) but I can't find it at the moment.

From what I understand it is advisable to work with a more recent version of llvm and staying more or less up to date with the releases.
If you stay at 3.1 and need some features from top of tree someday you may have a lot of work.

As far as git workflow is concerned:
In opposition to svn you have branches and it is recommended to work on a personal branch whenever possible. There you add features/fixes and test them. You merge them afterwards into the master branch (preferably rebasing first (if your branch isn't public) to prevent merge commits).
This way you won't have problems to pull from upstream as the pull from the master branch will always be a fast-forward one.

Anyways, keep up the work.

Hi stev47, thank you for noticing the fork and joining Cemetech! (You can always introduce yourself in this topic)

We pulled in LLVM 3.2 and are working on that. I am learning TableGen, however my knowledge is currently spent on getting the build system working to build the Z80 target in the standard way.

Do you have any recommendations on where I can start learning TableGen? I am of course reading the TableGen overview since I know nothing of the language, but there aren't any tiny llvm targets that I can look at to know what everything does :/

For git, I guess I just haven't used it enough. I use svn for GlassOS, a z80 OS for ti8x graphing calcs (currently uses SDCC for a C compiler, but LLVM could prove to be a large improvement if registers are used for parameters rather than the stack).

I will look at the sourceforge project. Were they using your code as a starting point, or from scratch?

Again, glad to see that you noticed the fork Would you still be interested in working on this?