From: mutazilah@gmail.com   
      
   "BGB"  wrote in message   
   news:vaoach$3l2k0$1@dont-email.me...   
      
   > >> Where, for my own ISA, I am using BGBCC.   
   > >>     BGBCC is ~ 250 kLOC, and mostly compiles C;   
   > >   
   > > We have struggled and struggled and struggled to try to get   
   > > a public domain C90 compiler written in C90 to produce 386   
   > > assembler.   
   > >   
   > > There have been a large number of talented people who tried   
   > > to do this and fell flat on their face. I never even tried.   
   > >   
   > > The closest we have is SubC.   
   > >   
   > > Is this a market gap you are able and interested in filling?   
   > >   
   > > By either modifying BGBCC (and making public domain if   
   > > it isn't already), or using your skills to put SubC over the line?   
   > >   
   >   
   > It is MIT licensed, but doesn't currently produce x86 or x86-64 (as I   
   > mostly just used MSVC and GCC for PC based development).   
   >   
   > Rather, backends it currently has are:   
   >    BJX2   
   >    BJX1 and SH-4 (old)   
   >    BSR1 (short lived)   
   >      Another custom ISA, inspired by SuperH and MSP430.   
   > Very early versions targeted x86 and x86-64.   
   >    But, this backend was dropped long ago.   
   >    Did briefly attempt a backend for 32-bit ARM, but this was not kept.   
   >      This was in a different fork.   
   >      Performance of the generated code was quite terrible.   
   >      Didn't really seem worth the bother at the time.   
   >   
   > Much of the current backend was initially derived from an 'FRBC'   
   > backend, which was an attempt to do a Dalvik style register IR.   
   > The FRBC VM was dropped, as while fast, the VM was very bulky in terms   
   > of code footprint (combinatorial mess). But, at the time, wasn't a big   
   > step to go from a register IR to an actual CPU ISA, and (for a sensibly   
   > designed ISA), it is possible to emulate things at similar speeds to   
   > what one could get with a similar VM.   
   >   
   > My current emulator (for BJX2) is kinda slow, but this is more because   
   > it is usually trying to be cycle-accurate, and as long as it is possible   
   > for it to be (on the PC side of things) faster than the CPU core on the   
   > target FPGA, this is good enough...   
   >   
   >   
   >   
   > AFAIK, whether declaring something as public domain is legally   
   > recognized depends on jurisdiction. I think this is why CC0 exists.   
      
   And if you believe that, then you're welcome to say that this   
   is public domain, but you may follow the CC0 license instead   
   if you wish.   
      
   > Personally, I am not all that likely to bother with going after anyone   
   > who breaks the terms of the MIT license, as it is pretty close to "do   
   > whatever", similar for 3 clause BSD.   
      
   We're not after someone who is allegedly "not going to go   
   after anyone", we're after some code that is NOT OWNED   
   by the original author because he/she has RELEASED IT   
   TO THE PUBLIC DOMAIN.   
      
   If the answer is "no", then please say "no".   
      
   > It is also more C95 style, making significant use of // comments and   
   > "long long" and similar, more or less the C dialect that MSVC supported   
   > until around 2015 or so (when they started adding C99 stuff).   
      
   Actually, so long as it handles C90 syntax, this would be   
   a step up from what we currently have.   
      
   > I had at one point wanted to try to make a smaller / lighter weight C   
   > compiler, but this effort mostly fizzled out (when it started to become   
   > obvious that I wasn't going to be able to pull off a usable C compiler   
   > in less LOC than the Doom engine, which was part of the original design   
   > goal).   
      
   We don't necessarily need a lighter weight compiler. That   
   could be done at a later date. The first thing we need is   
   something that will take C90 syntax.   
      
   > I had also wanted to go directly from ASTs to ASM, say:   
   >    Preproc -> Parser/AST -> ASM -> OBJ -> Binary   
   > Vs:   
   >    Preproc -> Parser/AST -> RIL -> 3AC -> Machine Code -> Binary   
   >   
   >   
   > But, likely the RIL and 3AC stages are in-fact useful.   
   > And, it now seems like a stack-based IR (for intermediate storage) has   
   > more advantages than either an SSA based IR (like in Clang/LLVM) or   
   > traditional object files (like COFF or ELF). Well, except in terms of   
   > performance and memory overhead (vs COFF or ELF), where in this case the   
   > "linker" needs to do most of the heavy lifting (and needs to have enough   
   > memory to deal with the entire program).   
   >   
   > A traditional linker need only deal with compiled machine-code, so is   
   > more a task of shuffling memory around and doing relocs; with the   
   > compiler parts only needing to deal with a single translation unit.   
   > Though, the main "highly memory intensive" part of the process tends to   
   > be parsing and dealing with ASTs, which is gone by the time one is   
   > dealing with a stack bytecode; but, there is still the memory cost of   
   > translating the bytecode into 3AC to actually compile stuff. This   
   > doesn't ask much by modern PC standards, but is asking a lot when RAM is   
   > measured in MB and one wants to be able to run stuff without an MMU (it   
   > is a downside if the compiler tends to use enough RAM as to make virtual   
   > memory essentially mandatory to be able to run the compiler).   
   >   
   >   
   > But, RIL's design still leaves some things to be desired. As-is, it   
   > mostly exists as big linear blobs of bytecode, and the compiler needs to   
   > deal with the whole thing at once. This mostly works for a compiler, but   
   > would be undesirable for use by a VM (or for a more resource-constrained   
   > compiler, which can't just load everything all at once).   
   >   
   > But, efforts to change this have tended to fizzle out.   
      
   We don't need the world's best C compiler. At least not   
   as a first step.   
      
   > > I can only guarantee that I will recognize your work if you do   
   > > this, but that's potentially better than no-one at all. Also, there   
   > > is likely to be more than just me who appreciate having a C90   
   > > compiler in the public domain.   
   > >   
   > > We currently use the copyrighted GCC 3.2.3 (my modification   
   > > of it) in order to get full C90.   
   > >   
   > > There are some other targets of interest besides 386, namely   
   > > 370, ARM32, x64, 68000. ARM64 would be good too, but   
   > > we don't have that at all.   
   > >   
   > > 8086 is another target of interest. SubC is already being used   
   > > to produce a bootloader for PDOS/386, but Watcom is better   
   > > because of SubC's primitive nature.   
   > >   
   >   
   > BGBCC doesn't currently support any 16-bit targets, mostly only 32 and   
   > 64 (well, and an experimental mode that used 128-bit pointers, but this   
   > was shelved due to "at best, it was gonna suck").   
      
   32 and 64 would be a fantastic start and 99% of the problem..   
      
   But if the answer is "no", the answer is "no".   
      
   So far the answer is an implied "no".   
      
   BFN. Paul.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)