I am looking for ideas for tasks to start on stage2.
On 8/8/20 6:07 AM, Maciej Walczak wrote: > I am looking for ideas for tasks to start on stage2. > In this video I did a sort of demo/tour/overview of stage2: https://www.youtube.com/watch?v=3CtQAaWUZrY That might be a nice introduction to the build process and some of the tools available to work on stage2. As far as tasks go, there is plenty to do. Picking something that is the right difficulty, has low chance of merge conflicts, and does not depend on other tasks is a bit tricky at the moment. Here are some tasks in the "to do" column on the left-hand side: https://github.com/ziglang/zig/projects/2 I would be happy to explain more if you have any specific questions. Here are some specific ideas: * Improve the implementation of copy_file_range, which stage2 depends on when it needs to move file data around, to take advantage of OS syscalls where they are available. This is a general standard library improvement that will benefit many applications, not just the self-hosted compiler. * Implement compile error notes and colored compile error output. Possibly even adding the ability to highlight "token ranges" when emitting compile errors. This may be a little bit trickier than it seems at first, because it may (or maybe not) involve changing the way that Zig deals with source locations (currently byte offsets). The trick is going to be keeping the number of bytes per ZIR instruction and other things small (currently a single pointer-sized integer), while facilitating quick .debug_line output which must know about line/column numbers, and facilitating compile errors and notes that point specifically to individual tokens. * Clean up the link.zig code that deals with allocations of various things. There are 3 ad-hoc allocation implementations (allocating ELF sections within the file, allocating virtual memory for function bodies, allocating .debug_line sections) and probably more to be added. This is a tricky task but it would be great if we could have better test coverage for these things, and maybe even it would make sense to have some kind of "allocation abstraction" for these things so that the logic would not have to be duplicated. I will be a little bit fussy here however, about doing the right level of abstraction, and keeping the structs to have simple data fields where it is easy to understand how much memory they are going to take per Decl / per Function / per File. There is a strong emphasis in stage2 of working on the memory layout of things first, and then writing the code surrounding it to fit. * Implement more of astgen.zig which is the part that transforms zig source code into ZIR instructions. * Implement more of zir_sema.zig which is the part that does semantic analysis of ZIR instructions and emits typed IR instructions. Much of this logic can be ported from ir.cpp, however, care must be taken, because stage2 works differently than stage1 in many (useful!) ways. * Implement more of the C backend. pixelherodev started this effort, but seems to have abandoned it. Feel free to rework the code if it doesn't seem like the right way to do things (codegen.zig would be a good reference in this case). This backend is going to be really useful soon, because there is a potential for it to be the way that we escape from stage1 by having stage2 emit stage1.c and then we can start using that as the new stage1. Hope that helps, happy to answer any follow up questions. Andrew
I didn't abandon the C backend, I was busy for a while and didn't have time to work on it. I hope to get more work done on it today, actually. (Accidentally responded to Andrew specifically, sorry about that!) - Noam Preil (~pixelherodev) -- Email domain proudly hosted at https://migadu.com