2 2

Good first time tasks in stage2

Message ID
DKIM signature
Download raw message
I am looking for ideas for tasks to start on stage2.
Message ID
<CAAuKPqactpnT1HuGzc93b7TOggEPTgghYH58N2mBgiFea8D=8g@mail.gmail.com> (view parent)
DKIM signature
Download raw message
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:

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:
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.

Message ID
<f8e63adc-2349-178b-5fc3-1a21feaa0495@ziglang.org> (view parent)
DKIM signature
Download raw message
DKIM signature: fail
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
Reply to thread Export thread (mbox)