search for: stellmann

...en, so I'm really looking forward to the point where the first regular C sources can be compiled and see the magic happening in action live :) ------------------------------------------------------------------------ *From:* Bruce Hoult *Sent:* Sunday, Jul 22, 2018 9:42 AM WEST *To:* Michael Stellmann *Cc:* LLVM Developers Mailing List *Subject:* [llvm-dev] Finding scratch register after function call > I had a quick look at some reference material this time :-) I also did > some work on a DEC Rainbow and a Kaypro CP/M luggable a few years > later. The compilers of the time were just...

Thanks Bruce, and elaborately as ever. Again, I'm surprised about your very thorough Z80 knowledge when you said you only did little on the ZX81 in the eighties :D OK, understood. I was first thinking about doing something like this for small frames: 1. push bc # 1 byte; 11 cycles - part of call frame-cleanup: save scratch register +-----begin call-related 2. ld

.../ limited operators as possible in a 1:1 way, leading to simpler lowering code (not sure if I am using the right words here)? Thanks, Michael ------------------------------------------------------------------------ *From:* Bruce Hoult *Sent:* Wednesday, Jul 25, 2018 11:33 PM WEST *To:* Michael Stellmann *Cc:* LLVM Developers Mailing List *Subject:* [llvm-dev] Question about target instruction optimization > This is so far down the list of problems you'll have (and the > difference so trivial to program size and speed) that I think you > should ignore it until you have a working com...

This is a question about optimizing the code generation in a (new) Z80 backend: The CPU has a couple of 8 bit physical registers, e.g. H, L, D and E, which are overlaid in 16 bit register pairs named HL and DE. It has also a native instruction to load a 16 bit immediate value into a 16 bit register pair (HL or DE), e.g.: LD HL,<imm16> Now when having a sequence of loading two 16

Hi, I'm trying to revive jacobly0's Z80 back-end (from https://github.com/jacobly0/llvm-z80) and build it with a current version of LLVM. Apart from some interface changes, I'm stuck at building the tables. Specifically, the generation of the DAG instruction selector causes an assertion in the table generator: Assertion failed: Ops.size() >= NumSrcResults &&

I'm working on a Z80 backend and am trying to efficiently lower SEXT, specifically 8 to 16 bit, in LowerOperation() according to the following rules: The Z80 has 8 bit registers and 16 bit registers, which are aliased versions of two 8 bit registers. 8 bit registers are named A, H, L, D, E and some more. 16 bit registers are HL (composed of H + L), DE (D + E) - and some more - with L and

I'm working on defining the instructions and implementing the lowering code for a Z80 backend. For now, the backend supports only the native CPU-supported datatypes, which are 8 and 16 bits wide (i.e. no 32 bit long, float, ... yet). So far, a lot of the simple stuff like immediate loads and return values is very straightforward, but now I got stuck with ISD::TRUNCATE, as in:

For a Z80 backend, "eliminateCallFramePseudoInstr()" shall adjust the stack pointer in three possible ways, e.g. after a function call, depending on the amount (= adjustment size) *and some other rules*: 1. via one or more target "pop <reg>" instructions (SP increments +2 per instruction), using an unused reg (disregarding the contents after the operation), followed