similar to: Finding scratch register after function call

Yes, such optimizations are something for the "last 20%" of the project, nice to have's. As of now, I have yet to get a feeling of what LLVM can do on its own, depending on what it's from the instruction tables and where it needs help, and how much in other processing stages. As this affects the way how the instruction info table will be set-up, I appreciate your suggestions

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

>It should be possible to get llvm to produce very good code for the Z80... Yes, I was thinking that too. These techniques didn't exist back then, 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

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

Hello. I am playing with LLVM and trying to make Z80 (Zilog Z80) backend. The source code is attached. I have succesfully made some simple test. But now I have problem with ADD instruction. The source C code is: typedef struct { unsigned char id1; unsigned char id2; unsigned char id3; } testS; void simple() { testS test; test.id1 = 0x40; test.id2 = 0x80; test.id3 = 0xc0; } It

I've mentioned my sneaky plans to target the MOS6502 here before. The big issue I think is that a lot of instructions don't really have a choice for output register. It all just goes into the accumulator, X index, or Y index based on the specific instruction. So, my question is, when I'm defining my ins, outs and registers for these instructions, is it going to be a problem that

Hi Peter, I think the problem is that you did not explicitly define stack alignment in Z80TargetMachine.cpp DataLayout("e-p:16:8:8-i8:8:8-i16:8:8-i32:8:8-n8") Try to add S16 to the string if your stack is 2-byte aligned. Refer to http://llvm.org/docs/LangRef.html#datalayout . If it does not work, try to specify the layout in the input module using target layout directive. David On

Hello. I have played with DataLayout and found a solution with is uknown to me. I added S16 and also s0:16:16, but it had not worked. Then I found that in Z80FrameLowering.h I am calling TargetFrameLowering with stack aligment set to 8. So I changed it to 2 bytes. But this also didn't help. Then I changed llc to show TargetDataLayout and found that a option is set to a0:0:64. So I changed

Hi All, I'm a little stumped by the following problem. I've got a dataset with the following structure: idxy ix iy country (other variables) 1 1 1 c1 x1 2 1 2 c1 x2 3 1 3 c1 x3 . . . . . 3739 55 67 c7 x3739 3740 55 68 c7 x3740 where ix and

Hey all Im having a problem... Ok, this is the situation... I have a small product image, on which ive floated a div over it, and defined it as draggable. Now, this works, and i can drag it around no problem. great. but then, what i want to do is, based on the location of that dragable element from the top and the left, to move (using the Effect.MoveBy method) a larger image - so effective

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:

Dear all; Does anyone know how to add grid lines to a persp plot? I've tried using lines(trans3d..) but the lines of course are superimposed into the actual 3d surface and what I need is something like the plot shown in the following link: http://thermal.gg.utah.edu/tutorials/matlab/matlab_tutorial.html I'll appreciate any ideas Thanks PM

Dear List: I am having to build a block-diagonal matrix (vl) and am currently using the following code. I<-diag(sample.size) vl<-kronecker(I,vl.mat) This code works fine, but for large N, it is a huge memory hog. Is there a more efficient method for constructing vl? Thanks, Harold [[alternative HTML version deleted]]

The ivdep pragma is designed to do exactly what the name states - ignore vector dependencies.  Cray Research first implemented this in 1978 in their CFT compiler, and has supported it since. This pragma is typically used by application developers who want vectorized code when the compiler cannot automatically determine safety; it is not equivalent to the OpenMP SIMD pragma in that the compiler is

Hi all, I ran into this while trying to figure out why the X86 getSUBriOpcode/getADDriOpcode functions are duplicated, appearing once in X86RegisterInfo.cpp and once in X86FrameLowering.cpp, The method TargetRegisterInfo::eliminateCallFramePseudoInstr doesn't appear to really belong in this interface. It adds instructions into the MachineFunction given to it, which isn't what

Hi All. I'm writing storeRegToStackSlot and loadFromStackSlot function for my Target. This Target can store/load one byte (not all word) from FrameIndex. If I need to store 16 bit register I will must to split it to two instruction like this: BuildMI(MBB, MI, dl, get(Z80::LD8xmr)) .addFrameIndex(FrameIndex).addImm(0) .addReg(SrcReg, 0, Z80::subreg_lo); BuildMI(MBB, MI, dl,

I have a question about antialiasing when R generates bitmaps. (This follows a thread on the ggplot2 mailing list.) I mostly use R on Linux, although I sometimes use it in Mac and Windows as well. On Linux, I've found that plotting shapes 15-18 via cairo results in bad-looking output. The points are not antialiased, and they are jagged and misshapen. Plots generated in Windows also aren't

I've found the need to compute a version of order(x,y) where I want the sort order for *increasing* x and *decresing* y ... something we could imagine could be provided in the future as order(x,y, decreasing = c(FALSE, TRUE)) i.e., using a 'vectorized' decreasing argument. {No, I'm not volunteering right now!} I've found the following R-level solution and like to quiz

Inspired by Jason Turner's talk at CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” I got interested in writing a Zilog Z80 backend for LLVM. Jason actually did no such thing, but instead wrote a x86-to-6502 translator (reassembler he calls it) https://github.com/lefticus/x86-to-6502 So I'm now trying to bootstrap this project. Goal: - be