using an FPGA to emulate a vintage computer
in [FPGA]
|
From: Eric Chomko on 4 Mar 2010 12:15 On Mar 3, 7:06 pm, Greg Menke <guse...(a)comcast.net> wrote: > Peter Flass <Peter_Fl...(a)Yahoo.com> writes: > > Michael Wojcik wrote: > >> Peter Flass wrote: > >>> Hey! C's finally caught up to PL/I. Only took them 50 years, and then > >>> of course all the features are just tacked-on in true C fashion, instead > >>> of thought-through. > > >> Well, that's rather insulting to the members of WG14, who spent a > >> decade designing those features. Fortunately, they published the > >> Rationale showing that, in fact, they were thought through.[1] And a > >> great deal of documentation describing the process is available in the > >> archives.[2] > > >> If you'd care to show why you think otherwise, perhaps there would be > >> some grounds for debate. > > > "The flexible array must be last"? > > > "sizeof applied to the structure ignores the array but counts any > > padding before it"? > > > C is a collection of ad-hoc ideas. WG14 may have put a great deal of > > thought into how to extend it without breaking the existing mosh, but > > that's my point, it's still a mosh. > > iostream formatting operators, because we really need more operator > overloading and no enhancements are too bizarre in service of making > everything, (for particular values of everything), specialized? > > Oh but wait, you can compile, install and dig your way through Boost so > as to avoid the fun & games of vanilla iostream. > > Thank goodness printf and friends are still around. More generally when speaking about C++, than goodness C is still around. > > Which I suppose isn't an argument that the feature wasn't designed, but > is perhaps in support of the "ad-hoc" argument. One more wacky idea > thrown on the pile for the amusement of the programmer. > > Gregm
From: Scott Lurndal on 4 Mar 2010 14:05 Eric Chomko <pne.chomko(a)comcast.net> writes: >More generally when speaking about C++, than goodness C is still >around. One can actually write very maintainable and quite performant applications in C++ by restricting the subset of C++ the version 2.1 flavor (no STL, no Templates, no Exceptions, no run-time typing). Basically C with classes. One can still use printf, snprintf, setjmp/longjmp etc, while reaping the data hiding and inheritance/interface benefits of C++. I've worked on three different operating systems or hypervisors written in such a restricted dialect. And yes, I think the iostream stuff is a useless abominable hack. scott
From: Peter Flass on 4 Mar 2010 16:45 Eric Chomko wrote: > On Mar 3, 7:06 pm, Greg Menke <guse...(a)comcast.net> wrote: >> Peter Flass <Peter_Fl...(a)Yahoo.com> writes: >>> Michael Wojcik wrote: >>>> Peter Flass wrote: >>>>> Hey! C's finally caught up to PL/I. Only took them 50 years, and then >>>>> of course all the features are just tacked-on in true C fashion, instead >>>>> of thought-through. >>>> Well, that's rather insulting to the members of WG14, who spent a >>>> decade designing those features. Fortunately, they published the >>>> Rationale showing that, in fact, they were thought through.[1] And a >>>> great deal of documentation describing the process is available in the >>>> archives.[2] >>>> If you'd care to show why you think otherwise, perhaps there would be >>>> some grounds for debate. >>> "The flexible array must be last"? >>> "sizeof applied to the structure ignores the array but counts any >>> padding before it"? >>> C is a collection of ad-hoc ideas. WG14 may have put a great deal of >>> thought into how to extend it without breaking the existing mosh, but >>> that's my point, it's still a mosh. >> iostream formatting operators, because we really need more operator >> overloading and no enhancements are too bizarre in service of making >> everything, (for particular values of everything), specialized? >> >> Oh but wait, you can compile, install and dig your way through Boost so >> as to avoid the fun & games of vanilla iostream. >> >> Thank goodness printf and friends are still around. > > More generally when speaking about C++, than goodness C is still > around. > I've said before, C started out as a fairly simple and clean language, with possibly a few rough spots. Unfortunately instead of accepting it on its own terms, and maybe coming up with "D", people tried to turn it into a real 3GL, but then it gets in its own way. It's lots of fun reading some of the Gnu stuff to see a language less readable than APL.
From: Greg Menke on 4 Mar 2010 19:52 scott(a)slp53.sl.home (Scott Lurndal) writes: > Eric Chomko <pne.chomko(a)comcast.net> writes: > >>More generally when speaking about C++, than goodness C is still >>around. > > One can actually write very maintainable and quite performant applications > in C++ by restricting the subset of C++ the version 2.1 flavor (no STL, > no Templates, no Exceptions, no run-time typing). Basically C with classes. > > One can still use printf, snprintf, setjmp/longjmp etc, while reaping the > data hiding and inheritance/interface benefits of C++. > > I've worked on three different operating systems or hypervisors written in > such a restricted dialect. > > And yes, I think the iostream stuff is a useless abominable hack. > > scott C++ does make for a nice "type-safe linking" C compiler. The compile & link time type checking is an improvement, but no so much when it comes time to dig into the object code and symbol tables. Probably would also agree wrt classes etc, as clumsy as the C++ object model is, it improves on structs. But I think having exceptions around is of help- goto's out of nested code always make me feel unclean. Runtime typing in C++, now that is pretty funny! Gregm
From: Brian Boutel on 4 Mar 2010 23:02
Michael Wojcik wrote: > Charles Richmond wrote: >> A "thunk" was *and* is a method for implementing "call by name". But a >> compiler providing "thunks" has *not* been written for some time now. > > That's rather dubious. > > We don't know that no one has written a compiler that provides > ALGOL-style thunks recently. To demonstrate that you'd have to prove a > negative. > > If we relax the definition to allow named as well as anonymous > functions, then someone could argue that get-accessors for properties > are thunks, and those are quite common in modern languages. > (Sorry this is a week late - I'm still catching up from being away) In functional languages with lazy evaluation (e.g. Haskell) arguments are passed unevaluated, so an actual argument that is an expression needs to be parcelled up as a piece of code and an environment in which is is to be evaluated (i.e the bindings of the free variables in the code). This amounts to a thunk. The only difference from call by name is that it doesn't require re-evaluation on every reference, as the absence of explicit assignment in the language guarantees that the value will not change between references in the same function invocation. --brian -- Wellington, New Zealand "I don't respond to Christopher Hitchens in public, on the general principle that you should never mud-wrestle with a pig because you both get filthy and the pig likes it." -- Tony Judt |