Quadibloc wrote:
> On Feb 8, 12:46 am, Mike Hore <mike_hore...@OVE.invalid.aapt.net.au>
> wrote:
>> (see below) wrote:
>>> On 05/02/2010 18:19, in article
>>> badc12c3-cb2b-4ce9-9543-237d60fc2...@o8g2000vbm.googlegroups.com, "Eric
>>> Chomko" <pne.cho...@comcast.net> wrote:
>>>> Has anyone created a copy machine of an old system using an FPGA? I
>>>> was wondering if it would be possible to take an entire SWTPC 6800 and
>>>> compile the schematics and have it run on an FPGA board.? Wouldn't
>>>> even have to be the latest Xylinx product, I suspect.
>>> I think such a project would valuable, and perhaps even more valuable if it
>>> aimed to recreate a machine of the "heroic" era -- a 7094, an
Atlas, or a
>>> KDF9, say. Perhaps even a Stretch.
>> A KDF9, maybe, but Stretch?  You'd have to be seriously masochistic, or
>> downright insane  :-)
> 
> I keep hoping for an FPGA that would be suitable for replicating the
> internal logic of an IBM 360/195, as an example, so that if I did
> build a replica of a computer, I could have a reasonably efficient
> implementation which would give performance at least roughly in the
> ballpark of a Pentium - at least an early one.
> 

I'd like to see a Honeywell Multics machine done in FPGA.  Doubt I'll 
ever have time, though.

Eric Chomko wrote:
> On Mar 3, 7:06 pm, Greg Menke <guse...@comcast.net> wrote:
>> Peter Flass <Peter_Fl...@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.

s...@slp53.sl.home (Scott Lurndal) writes:


> Eric Chomko <p...@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

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

On Thu, 04 Mar 2010 16:45:40 -0500
Peter Flass <P...@Yahoo.com> wrote:

> 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 

	This also happened read about D here http://www.digitalmars.com/d/

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Mar 4, 1:20=A0pm, glen herrmannsfeldt
<g...@ugcs.caltech.edu> wrote:

> Does anyone know if the information needed to do that still exists?

I suspect it was _very_ closely guarded back in the day, because it
would have been a matter of very serious concern had the Russians been
able to make a 360/195 equivalent to top out their RJAD/EC line. So
I'm thinking more along the line of a design from scratch to match the
public specifications, working from the 360/91 descriptions in the
open literature, and adding a cache (which shouldn't be too difficult,
there being caches on OpenCores). I'm not saying *I* could do stuff
like that on my very own, but there's a lot out there one could use as
a starting point.

John Savard

On Feb 26, 4:56=A0am, Ahem A Rivet's Shot
<ste...@eircom.net> wrote:

> =A0 =A0 =A0 =A0 No, he's saying that C doesn't really implement an array =
type, the
> var[offset] syntax is just syntactic sugar for *(var + offset) which is w=
hy
> things like 3[x] work the same as x[3] in C.

Um, no.

x =3D y + 3 ;

in a C program will _not_ store in x the value of y plus the contents
of memory location 3.

On a big-endian machine,

long int x[5] ;
x[0] =3D 3 ;
x[1] =3D 12 ;
y =3D x[0] ;

or, on a little-endian machine,

long int x[5] ;
x[1] =3D 3 ;
x[0] =3D 12 ;
y =3D x[1] ;

will not result in zero being stored in y, since a long int variable
occupies more than one byte in storage, and hence the two assignments
are being made to overlapping variables.

Yes, C doesn't do _bounds checking_, but that is a far cry from
"syntactic sugar for variable plus address offset".

John Savard

On Feb 22, 3:53=A0pm, Peter Flass
<Peter_Fl...@Yahoo.com> wrote:

> PL/I can be, but doesn't have to be. =A0If the arguments of a procedure
> match the parameters, only the argument address (and possibly a
> descriptor address for strings structures, and arrays) is passed.

Doesn't PL/I (or, rather, normal implementations thereof) support
separate compilation of subroutines, just like FORTRAN and COBOL?

John Savard

On Feb 22, 2:53=A0pm, Eric Chomko
<pne.cho...@comcast.net> wrote:
> This was pre-RISC days and the whole computer
> architecture idea
> based upon a high-level language never really took off. Nor did the
> use of a medium
> level language like Forth as far as I can tell.

Well, naturally not.

Both of those ideas got you less performance per dollar than the use
of a conventional architecture, with compilation by a highly-
optimizing FORTRAN compiler.

I mean, computer cycles cost real money in those days.

Later on, in the microcomputer era, the even less efficient use of
interpreters like BASIC was popular because it was an easy way to
bridge the gap between what the microprocessors could do, and what was
convenient for people to program in. But serious applications - which,
in the case of home computers, largely meant video games - were
programmed in assembler, until things improved to the point where C
was an alternative.

John Savard

On Fri, 5 Mar 2010 09:07:31 -0800 (PST)
Quadibloc <j...@ecn.ab.ca> wrote:

> On Feb 26, 4:56 am, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> 
> >         No, he's saying that C doesn't really implement an array type,
> > the var[offset] syntax is just syntactic sugar for *(var + offset)
> > which is why things like 3[x] work the same as x[3] in C.
> 
> Um, no.
> 
> x = y + 3 ;
> 
> in a C program will _not_ store in x the value of y plus the contents
> of memory location 3.

	No but x = *(y + 3) will store in x the contents of the memory
location at 3 + the value of y just as x = y[3] will and x = 3[y] will,
which is what I stated. You missed out the all important * and ()s.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/