From: alexfrunews@gmail.com
On Sunday, January 30, 2022 at 9:02:01 AM UTC-8, anti...@math.uni.wroc.pl
wrote:
> muta...@gmail.com wrote:
...
> > I haven't had a need for any of that stuff in my OS-related
> > code so far, and can presumably work around it if I do. Or
> > I may be able to modify SubC myself, as I have bought
> > Nil's book and am studying the code. Some of it was too
> > difficult for me to understand though, so I'm hoping no
> > problem occurs there. I have noticed that I'm not very good
> > with algorithms. Most code that I have written hasn't
> > involved complex algorithms. And so far I haven't been able
> > to find anyone willing to modify SubC even if I pay them.
[This is more of a response to Paul than Waldek].
The code has to be understandable and has to have some
potential for anyone to mess with it.
I think so far only Ben Lunt has been willing to go through the
ugly Smaller C source to try to adapt it to his needs.
I haven't heard of any other attempts to get into it as deep
as he did.
I'm not willing to make improvements into Smaller C myself
because Smaller C suffers from the same design problems that
SubC and the original Small C (by Hendrix and Cain) do.
It's hard to modify it in order to extend and improve significantly
beyond what's already there.
That's the very thing Waldek is saying below.
...
> Concerning SubC, it looks like rather bad start for
> a full C compiler. There are design decisions that
> make it more complex than necessary simultanously
> limiting what it can do. In particular using two symbol
> tables and acumulator model for code generation.
Yep, there are many different design problems that
are very limiting further development. It's more fruitful to
redo the bad design and rewrite the implementation.
Alex
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
