Looks like we have some things that are abstract which shouldn't be. In particular, some methods which need to be overridden from pure virtual versions in their super classes.
Take a look at my branch here:
https://github.com/stev47/llvm/tree/z80
I just fetched the svn repository from the llvm-z80 project at sourceforge, converted to a git repository and rebased onto a trunk version of llvm.
After some build fixes it compiled.
Might help you to get started.
Not sure if anything works beyond compiling llvm with the z80 target.
https://github.com/stev47/llvm/tree/z80
I just fetched the svn repository from the llvm-z80 project at sourceforge, converted to a git repository and rebased onto a trunk version of llvm.
After some build fixes it compiled.
Might help you to get started.
Not sure if anything works beyond compiling llvm with the z80 target.
Might be a good idea to merge in the stuff I did with supporting undocumented instructions (or not) and push some changes to github?
I found this article to be enlightening, and I suspect It'll offer some useful insights to you guys too. Offers a good dataflow analysis for when you're converting IR to machine representations.
http://eli.thegreenplace.net/2012/11/24/life-of-an-instruction-in-llvm/
http://eli.thegreenplace.net/2012/11/24/life-of-an-instruction-in-llvm/
Ooh, LLVM compiling for z80 would be AWESOME! Not only do you get good C compiling, but Clang also supports C++11 and Objective-C/C++!
Hmm...what to put here....
I have picked this up due to SDCC generating invalid z80 code (causing memory corruption, not acceptable). I am currently trying to get to generating asm output. This requires a lot of classes to be made with little understanding of what everything means. The documents that I have simply say "make this class" but don't show any code for it, or they show partial code, but don't say what any of it means or does.
Now, for questions:
Now, for questions:
- What does the RegisterInfo class do? I don't understand how the overridden functions are supposed to work.
- What does the ISelLowering class do? What are the functions I need to override?
- Are subtargets required to get started?
- What do all of these tabletgen inc's do, anyways? I have read over them, but the output has little meaning to me.
- Is there any documentation on what anything is supposed to do and how I should do it? MSP430 target has helped for showing me the headers, but I have no idea what is going on.
I suggest to post a blurb of text to llvm-users or llvm-dev, containing your latest post here, the references you used (e.g. "life of an instruction" linked above, or more details on "The documents that I have" that you mentioned above), etc.
I think that llvm-users or llvm-dev is the place where you'll get the most help, and as a bonus, the LLVM contributors may use this as a motivation to spend a bit of time expanding the documentation / FAQ, so that everyone benefits
#llvm on oftc.net might work, but all forms of IM (with real-time constraint) are less suitable than e-mails / forums (without the real-time constraint) for discussions of this kind.
I think that llvm-users or llvm-dev is the place where you'll get the most help, and as a bonus, the LLVM contributors may use this as a motivation to spend a bit of time expanding the documentation / FAQ, so that everyone benefits
#llvm on oftc.net might work, but all forms of IM (with real-time constraint) are less suitable than e-mails / forums (without the real-time constraint) for discussions of this kind.
I will probably do that soon. I am trying to get rid of this 'undefined reference to vtable for llvm::Z80InstPrinter' error first.
Also, I've just thought that examining the recent AArch64 patches (64-bit ARM, http://llvm-reviews.chandlerc.com/D284 & http://llvm-reviews.chandlerc.com/D285 ), and/or the slightly older AMD R600 patches (GPU, it was shortly after the 3.2 release), might provide some answers to your questions, I don't know.
Thanks for those links, but sadly they have 0 comments at all, so I have no idea where anyone just generates these classes...
Anyways, progress has been made! I am working on a passconfig just to even get llc to be happy.
I will get on to the llvm IRC channel and see if anyone can point me in the right direction for my questions.
Anyways, progress has been made! I am working on a passconfig just to even get llc to be happy.
I will get on to the llvm IRC channel and see if anyone can point me in the right direction for my questions.
AHelper wrote:
I will get on to the llvm IRC channel and see if anyone can point me in the right direction for my questions.
This seems like the best option
I'm remaking my Quick Assembly SDK for linux and will include source.
Currently it takes a simple high level language and spits out z80 code for whatever model specified. Also converts bitmaps to .db, dc.b or C array for all TI screen sizes. Possibly going to include compression and other options.
The Windows release on ticalc is very old, but stable.
So, Chris pointed me towards you guys. If we can collaborate that'd be great. I currently only have access to emulators.
Currently it takes a simple high level language and spits out z80 code for whatever model specified. Also converts bitmaps to .db, dc.b or C array for all TI screen sizes. Possibly going to include compression and other options.
The Windows release on ticalc is very old, but stable.
So, Chris pointed me towards you guys. If we can collaborate that'd be great. I currently only have access to emulators.
This seems like a useful resource: http://jonathan2251.github.io/lbd/llvmstructure.html
[edit]
Apparently the sourceforge project that we were all looking at earlier has had continued updates (and moved to GitHub): https://github.com/earl1k
[edit]
Apparently the sourceforge project that we were all looking at earlier has had continued updates (and moved to GitHub): https://github.com/earl1k
Any updates on this? I am still curious about what can we can do to support high level languages. A LLVM backend would be a break through, right?
The github link from my last post seems to be under active development and have a z80 target for Clang + LLVM, but I haven't put them to the test yet on anything significant, since I haven't worked on my calculator oriented C projects for a while.
This thread on the LLVM ML regarding a 6502 target is relevant. The 6502 and Z80 aren't entirely dissimilar machines. General opinion is pessimistic of the utility of such a thing.
Feeding LLVM IR (or a subset of it) into a custom backend sounds like a potentially useful approach to this kind of problem. You can ignore the problems of parsing input code and get all of LLVM's non-machine-specific optimizations (delicious CSE and constant folding..) for free, but don't need to bend the code generator to fit machines that are quite unlike what it was built for.
Quote:
In another life I help look ater the ACK compiler suite, which is
ancient and crufty and produces terrible code, but dates from about the
era when the 6502 was still a thing and I've played with its 6502 code
generator (and the 8080 code generator); these processors will basically
not run modern languages acceptably. It's because modern languages are
all stack-frame based, and these processors don't have any support for
stack relative accesses.
On the Z80 you can just about fake it by using ix or iy as a user stack
pointer, but it's painfully slow, painfully bloaty (8 bytes of code to
read or write a 16-bit value from the stack frame!) and basically just
painful. I believe later Z80s eventually gained a stack-relative load
instruction, but I don't know if there was a corresponding store.
The 6502 isn't quite as bad. If your user stack pointer is in zero page,
you can use indirect indexed to give access to a 256-byte stack frame,
but it's not pretty:
ldy #offset
lda (sp), y # load high(?) byte
iny
ldx (sp), y # load low byte
...seven bytes, I think.
At least it's not as bad as the 8080.
Being able to forbid recursion and therefore map every stack frame
statically into RAM would improve things no end, as now every stack slot
has a compile-time known address; I remember asking here about this ages
back and was told that there wasn't a built-in pass to do this, but it
would be fairly easy to do. *shrug*
Or you could just start using FORTRAN.
ancient and crufty and produces terrible code, but dates from about the
era when the 6502 was still a thing and I've played with its 6502 code
generator (and the 8080 code generator); these processors will basically
not run modern languages acceptably. It's because modern languages are
all stack-frame based, and these processors don't have any support for
stack relative accesses.
On the Z80 you can just about fake it by using ix or iy as a user stack
pointer, but it's painfully slow, painfully bloaty (8 bytes of code to
read or write a 16-bit value from the stack frame!) and basically just
painful. I believe later Z80s eventually gained a stack-relative load
instruction, but I don't know if there was a corresponding store.
The 6502 isn't quite as bad. If your user stack pointer is in zero page,
you can use indirect indexed to give access to a 256-byte stack frame,
but it's not pretty:
ldy #offset
lda (sp), y # load high(?) byte
iny
ldx (sp), y # load low byte
...seven bytes, I think.
At least it's not as bad as the 8080.
Being able to forbid recursion and therefore map every stack frame
statically into RAM would improve things no end, as now every stack slot
has a compile-time known address; I remember asking here about this ages
back and was told that there wasn't a built-in pass to do this, but it
would be fairly easy to do. *shrug*
Or you could just start using FORTRAN.
Quote:
Fundamentally, you have to ask what you’re looking to get out of this. If it’s just for fun, or if you just want to get (say) C++11 to run on your 6502 without caring about the low-level performance, that’s definitely doable. But if you’re trying to actually build a production-grade 6502 compiler, you’ll find that you’re unlikely to benefit from most of the facilities that LLVM provides in the SelectionDAG and Machine layers. They’re simply built for machines that work very, very differently. I’m not claiming it’s impossible to bend them to your will, but I am questioning the value in doing so. I think you’d get a better result with less work if you translated out of LLVM IR into a code generation pipeline more specialized for the needs of a 6502.
Feeding LLVM IR (or a subset of it) into a custom backend sounds like a potentially useful approach to this kind of problem. You can ignore the problems of parsing input code and get all of LLVM's non-machine-specific optimizations (delicious CSE and constant folding..) for free, but don't need to bend the code generator to fit machines that are quite unlike what it was built for.
That's a reasonable idea, although let's be honest that "Production grade compiler" is probably not the goal here for the definition of "Production grade compiler" that applies to most software engineering tasks.
[edit]
Incidentally, I still haven't dug into the guts of the implementation I linked in my last post, but it did generate this assembly:
Code:
from this test file which I fed it:
Code:
However, I get instruction lowering errrors if I try to compile, so obviously it's incomplete.
Code:
(Though I'm surprised 32 bit math appears to be implemented and not 8 bit)
There's also no support for generating machine code or linking, as far as I can tell, because trying to generate an object file instead of assembly results in trying to use the gcc x86 assembler.
[edit]
Incidentally, I still haven't dug into the guts of the implementation I linked in my last post, but it did generate this assembly:
Code:
.file "test.c"
.text
.globl main
.type main,@function
main:
push iy
push ix
push de
push bc
ld ix, -16
add ix, sp
ld sp, ix
ld (ix+14), 0
ld (ix+15), 0
ld b, h
ld c, l
ld (ix+12), c
ld (ix+13), b
ld c, (ix+26)
ld b, (ix+27)
ld (ix+10), c
ld (ix+11), b
ld (ix+8), 1
ld (ix+9), 0
ld (ix+6), 2
ld (ix+7), 0
ld e, (ix+8)
ld d, (ix+9)
ld a, e
sla a
rl d
push iy
pop de
ld (ix+8), e
ld (ix+9), d
ld e, (ix+6)
ld d, (ix+7)
ld (ix+4), l
ld (ix+5), h
push iy
pop hl
add hl, de
ld de, -6
add hl, de
ld (ix+6), l
ld (ix+7), h
ld e, (ix+4)
ld d, (ix+5)
ld (ix+2), e
ld (ix+3), d
ld (ix+0), c
ld (ix+1), b
ld ix, 16
add ix, sp
ld sp, ix
pop bc
pop de
pop ix
pop iy
ret
.tmp0:
.size main, .tmp0-main
from this test file which I fed it:
Code:
int main(int argc, const char * argv[]){
int a = 1;
int b = 2;
a *= b;
b = (a + b) - 6;
return b;
}
However, I get instruction lowering errrors if I try to compile, so obviously it's incomplete.
Code:
char main_(char n){
char a = 1;
char b = 2;
a *= b;
b = (a + b + n) - 6;
return b;
}
(Though I'm surprised 32 bit math appears to be implemented and not 8 bit)
There's also no support for generating machine code or linking, as far as I can tell, because trying to generate an object file instead of assembly results in trying to use the gcc x86 assembler.
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement