Yes, suggesting books, tutorials and other resources would be great. And this is one of the first things that would liven up a compiler subforum here or anywhere else. I use to skim through books and there are always details that catch my attention, and then I decide what would be best to start with.bwat wrote:I think it's the other way around - assuming I've understood you correctly. The generic stuff, w.r.t., compilers and OS stuff, has been done to death, but not on internet fora, instead it's in books. OS design, compiler design, and abstract machine design have been very well described by people who know how to teach. If you want book suggestions just ask.
To this list I would add, for each language, like C, talking about all of the conventions, both in general and for x86 (which is the most common by now). Not just calling convention, but things like where things will end up when compiled, their exact structure, and independent of a specific toolchain, relying only in the specifications, in a resumed way, and ways to make the outcome of the compiled programs for languages like C, as analogously transparent and simple as their Assembly counterparts (matching chunks in the binary with elements in the code -structures, variables, padding, etc.-). Besides, it would make much easier for anyone to learn that language, since everything would be much clearer, from start to end, including obvious bugs in the structure of the data and packing, etc., just as with Assembly programs, their code, and a disassembler.bwat wrote:What's missing, what's hard about it all, is the nitty gritty issues like:These things are still part of the black art of programming language implementation. The books that describe this are often old, obscure, and difficult for the hobbyist to get their hands on. A good forum will help with this.
- How do I write a high level debugger for this language?
- How do I write a control-C handler that throws an exception in this language so the user can break out of an infinite loop in his/her code and jump to their own handler?
- How do I implement, test, and document a logarithm function?
- How do I test my garbage collector?
- How do I best let the user define their own syntax extensions to the language?
W.r.t. comp.compilers, I've only had one conversation about that group with another professional compiler writer and we both had bad things to say about the moderator. It was quite funny actually.
Yes, it would in time. But, like in any other issue, it would require people who know about the subject to make it take off by adding material in a way that is simple to understand, before somebody asks (as seems to be the case with the Wiki too), and increasingly complete, avoiding questions that are far too specific to a toolchain/software piece/problem (these could be general-programming-related or whatever, unless they are truly relevant) as these questions would erode the overall interest on the really important topics.Combuster wrote:$.02 (and to get it back on track):dozniak wrote:It's not easy to set up a community, but if chase and mods are not against it, we could have a corner of this forum dedicated to that.
What I see with many people starting off on OS development, is that they can use a compiler from the instruction template they have always used - and for most desktop things you wouldn't need more than that. The result is that nobody knows how a toolchain really works until they get slapped hard by that mistake.
What happens next is that people will start to build runtime linkers - and at that point you will really need to know how the compiler outputs its stuff, and you will have to perform the necessary logic. Besides the task-specific linking, many system parts will end up having configuration files that will need to be read and parsed.
In other words, any sufficiently advanced OS has all the characteristic components of a (often simple) compiler, and depends quite a bit on the remaining parts of the compiler which the developer didn't need to write. In reverse, an actual compiler writer will need to be aware of how the OS deals with binaries without actually having to write that code.
So to include compiler development in this place would not be a far stretch and would probably have a symbiotic relation and a number of people migrating topics for fun and profit as a result.
----
Just as important is the follow-up question: would it take off if we tried? That one concerns me more actually.
That requirement is only known to the people who can start by adding the relevant starting points, so they are the ones who can figure that out. I for one have questions to ask and some little details to teach from time to time (I can do that in any of the sub-forums that already exist or in new ones), and that goes for many other areas (and they all fit in one way or another, at least for the users of any OS, to make it more interesting and serve as real-world tests for the capabilities of a kernel, to make something useful/educative with them).
