From: muta...@gmail.com   
      
   On Tuesday, February 1, 2022 at 6:56:26 AM UTC+11, anti...@math.uni.wroc.pl   
   wrote:   
      
   Hi Waldek. Thanks for your response.   
      
   > Hmm, algorithms in compiler are really not more complicated   
   > that algorithms in OS, database, BBS or even text editor.   
      
   Actually I struggled writing the FAT handling code   
   for writing too. It took years before I was able to   
   manage FAT16 only. Then someone from Slovakia   
   came along and made it support writing FAT12,   
   plus read and write FAT32, very quickly.   
      
   > There is problem of scale if you go for full compiler.   
   > But this is not too bad. Self compiling toy compiler   
   > for subset of C should be doable in 2-3 kloc. At about   
   > 20-25 kloc you should be able to get C90 compilance.   
   > In our time those are not really big programs.   
      
   20 kloc is very big and is not going to happen. What   
   we know is that we got 6 kloc in the last 50 years.   
   That's the real-world constraint.   
      
   > Already C90 have many things which are problematic to add   
   > to SubC. For me non-negotiable is full support for structs.   
      
   Ok. In my life I've never attempted to put a struct   
   on the stack, so I'm not going to miss anything.   
      
   > Floating point is another thing: it is reasonable to skip   
   > floating point in initial toy and add it only at later   
   > stage. But compiler structure should support easy addition,   
   > which means support different modes of variables. Which   
   > essentially meanst that if you want to add floating point   
   > later you should support different size of short and long   
   > releatively early.   
      
   Ok. I'll just assume I can't have floating point until   
   someone does a rewrite.   
      
   > Another thing is bitfields: personally I make little use   
   > of them, but sometimes they are quite useful. And there   
   > are a lot of programs using them.   
      
   If it can support my own code, that's a bloody good   
   start. And I don't think I have ever coded a bitfield.   
      
   > Scope in programming languages is recursive. You may claim   
   > that in C there are "really" only two scopes: file scope and   
   > function scope, but C90 standard says differently. So,   
   > for correct implementation of C you need to handle multiple   
   > scopes.   
      
   Ok, so that's variables that are defined in blocks instead   
   of at the beginning of a function. That did in fact bite me,   
   as I occasionally define variables in blocks, but I am   
   basically happy to "fix" that code so that it complies with   
   what SubC requires.   
      
   > Actually, the two symbol tables are tip of iceberg.   
   > Natural handling of types is recursive: pointer type   
   > contains type of thing pointed to, structure has list   
   > of fields and each of fields has its own type. In   
   > compiler it is convenient to have function types,   
   > such type has type of return value and argument types   
   > (C does not have function types but have pointers to   
   > functions and function type in compiler simplifies   
   > handling of pointers). SubC apparently encodes   
   > several combinations of types as integers and   
   > uses switches to handle them. Each switch branch   
   > needs its own code and due to combinations you   
   > get more code. With recursive handling you have   
   > less cases, so simpler code and more capable   
   > compiler.   
      
   Ok, I didn't fully understand that, but maybe SubC is   
   more understandable with some concrete discreet   
   types rather than generic recursion. I guess I will find   
   out when I reach that bit of the book.   
      
   > After second thought I think there is reason for   
   > unnecessary complexity in SubC. Namely, IIUC   
   > oryginally SubC had no support of structures.   
   > Nils wanted self-compilation which implied   
   > no structures in compiler. Recursive approach   
   > heavily depends on structures so Nils probably   
   > thought that without structures "flat" approach   
   > is simpler. But avoidance of structures (I saw   
   > only one structure type in SubC source) means   
   > that code is more complicated and harder to   
   > understand.   
      
   Ok.   
      
   > Concerning accumulator machine: there are several   
   > machine models usable for code generation. Basically,   
   > main part of compiler generates instructions for   
   > simple abstract machine and code generator is   
   > responsible for translating instructions from   
   > abstract version to actual machine code. In   
   > simplest version each abstract instruction is   
   > separately translated to one or more machine   
   > instructions.   
      
   I see.   
      
   > Popular abstract machines are stack machines   
   > and 3 address representation. What is wrong   
   > with accumulator machine as abstract target?   
   > Well, there is one accumulator so there are   
   > a lot of moves to/form accumulator. Which   
   > means more work when generating instructions   
   > for abstract machine and more work in code   
   > generator. And you either get poor object   
   > code or spent significant effort combining   
   > abstract instructions into machine instructions.   
      
   It might be easier to understand though, which   
   would be beneficial to me so that I can actually   
   support the product. Regarding poor object code -   
   I don't care about that. I just want the thing to work.   
   If a Good Samaritan turns up in the next 50 years   
   and writes a better public domain C compiler, that's   
   great. Otherwise, it's looking increasingly likely that   
   I am going to make SubC work for a practical task.   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)