dmcq (dmcq.delete@this.fano.co.uk) on July 13, 2015 3:24 pm wrote:
> sylt (no.delete@this.thanks.com) on July 13, 2015 2:19 pm wrote:
> > In any case, my experience with building low end, and very simple processors supports Linus point of
> > view that as the complexity and sophistication of the system increases the drive for stricter and simpler
> > to reason about rules also increases. I have not worked directly on memory ordering issues but for
> > similar issues where it was deemed easiest for the HW to punt the problem to software for simple designs
> > it soon became clear that defining simple intuitive rules and obeying them in HW gave the best over
> > all trade off of performance, complexity and ease of design as the system evolved.
>
> I fully agree with simpler and stricter - at the correct
> level. Assembler and machine code is not that level.
>
> > Sure, sometimes it feels rotten when some "unnecessary niceties" pops up in the critical paths but
> > after a few generations you are doing much more complicated things anyway for pure performance reasons
> > and the "unnecessary niceties" are a side show. After seeing this play out a few times I find it hard
> > to not go with strict and easy. This is especially true for us since we deliver inhouse and want to
> > optimize the productivity of HW, compiler and firmware teams combined. It's no good shipping some
> > blazing fast HW if you have no firmware because nobody can figure out how to program it.
>
> Strict and easy is very good for high level languages.

Can you provide some examples of the sort of high level languages you have in mind?