Re: Self modifying code, lambda calculus - Re: ENIAC programming

I wrote X.25 software in Fortran:-(. We had some machine specific routines One of my first professional jobs after college was with a company that created after-market hardware and software for Apollo workstations. Despite having a good Pascal, I was tasked with (and completed) a port of a

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-21 21:18, Fred Cisin wrote: [...] a first encounter with the notion, at least for me, involved FORTRAN, not any language. [...] I've always thought of FORTRAN as a language, so I am clearly missing something here. What? Probably a misspeak. But FORTRAN is more than simply a

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/21/2015 06:23 PM, Mouse wrote: Wirth & Co. started the project in FORTRAN, but gave up, particularly when it was realized that implementing data structures and recursion in FORTRAN was going to be a bit of a task. I think that if I wanted to build a Pascal compiler in FORTRAN I would

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/21/15 2:33 PM, Chuck Guzis wrote: PASCAL was first implemented in FORTRAN. Was there something before http://bitsavers.org/pdf/eth/pascal/ETH_Pascal_Listing_Nov72.pdf ? looks like 6600 assembler to me

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/21/2015 02:58 PM, Paul Koning wrote: PASCAL was first implemented in FORTRAN. Really? I find it hard to imagine that Wirth would use Fortran for a compiler. Never mind his background in structured languages -- writing a compiler in Fortran is just much harder. Not as hard as writing

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> On Sep 21, 2015, at 5:33 PM, Chuck Guzis wrote: > > On 09/21/2015 01:37 PM, Dave G4UGM wrote: > >> I wrote X.25 software in Fortran:-(. We had some machine specific >> routines to allow the Fortran code to wait for a packet to arrive. >> There was also a huge vector of

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/21/2015 02:24 AM, Johnny Billquist wrote: CHAIN is in no way similar to overlays. COMMONs, if available, is a nice way to preserve some data between different programs running. CHAIN is (like someone said), about the same as a LOAD followed by a RUN. So, how is this different than

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Chuck > Guzis > Sent: 21 September 2015 20:29 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk@classiccmp.org> > Subject: Re: Self modifying code,

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/21/2015 12:18 PM, Fred Cisin wrote: A REAL programmer can write a FORTRAN program in any language. Conversely, several languages were initially written in FORTRAN--it was among the most portable in the early days. Remember those programs that started out with a statement something

Re: Self modifying code, lambda calculus - Re: ENIAC programming

[...] a first encounter with the notion, at least for me, involved FORTRAN, not any language. [...] I've always thought of FORTRAN as a language, so I am clearly missing something here. What? Probably a misspeak. But FORTRAN is more than simply a language--it's a way of life. :) A REAL

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/21/2015 11:49 AM, Mouse wrote: [...] a first encounter with the notion, at least for me, involved FORTRAN, not any language. [...] I've always thought of FORTRAN as a language, so I am clearly missing something here. What? Probably a misspeak. But FORTRAN is more than simply a

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/21/2015 01:37 PM, Dave G4UGM wrote: I wrote X.25 software in Fortran:-(. We had some machine specific routines to allow the Fortran code to wait for a packet to arrive. There was also a huge vector of strings with matching integer arrays that allowed them to be chained together, and to

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-20 19:46, Chuck Guzis wrote: On 09/20/2015 09:00 AM, Peter Coghlan wrote: CHAIN is roughly equivelant to LOAD followed by RUN. Unlike LOAD, CHAIN can be issued from a program so it can be used for a kind of overlay where one program is run and then replaced by another program when

Re: eval() considered dodgy - Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 19 September 2015 at 19:45, Toby Thain wrote: > Thank God nobody would build such a thing into a modern language, especially > not the one that runs in almost every browser... Well, quite. :-) Or rather, :-( -- Liam Proven • Profile:

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 19 September 2015 at 19:53, tony duell wrote: > A lot of disk-based BASICs had a statement that would merge a program from > disk in this way. Sometimes the program had to be saved in ASCII, not > tokenised, > the BASIC interpretter then essentially read the file as

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> > But in everything from ZX BASIC to BBC BASIC to GWBASIC, loading a > program erases all lines of code in interpreter RAM and replaces the > whole program with the one loaded from disk, but leaves variables etc. > intact. > BBC BASIC (when running on a BBC Micro at least) does clear (most)

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 20 September 2015 at 13:54, Peter Coghlan wrote: > BBC BASIC (when running on a BBC Micro at least) does clear (most) variables > when a program is loaded. Most variables are stored in memory above the > program and if a small program was replaced by a larger program,

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/20/2015 09:00 AM, Peter Coghlan wrote: CHAIN is roughly equivelant to LOAD followed by RUN. Unlike LOAD, CHAIN can be issued from a program so it can be used for a kind of overlay where one program is run and then replaced by another program when it completes. However, like LOAD (and

Re: eval() considered dodgy - Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/19/2015 11:45 AM, Toby Thain wrote: Thank God nobody would build such a thing into a modern language, especially not the one that runs in almost every browser... No it just crashes when the AD server or Flash stops. --Toby Ben.

VAX 730 was Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/18/2015 10:15 PM, tony duell wrote: Simple answer. The control store functionality had to fit in the available space on one hex sized card, and 16K density DRAM was the only option. Allocating additional space to use 4K or 1K SRAM would have pushed the CPU design to an additional board,

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 18/09/2015 14:33, tony duell wrote: Are there any computers that do let you put microcode into RAM now-days. "Now-days"? There are some that do that, some of which are still in operational shape. Some VAXen, in particular, have something called "writable control store", which is

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> On Sep 19, 2015, at 5:25 AM, Rod Smallwood > wrote: > > Is an overlay self modifyig code? Yes (#2 in my list), but a controlled kind so it doesn't suffer from the maintainability issues of explicitly modified instructions. But it does require I-cache

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 19/09/2015 14:03, Paul Koning wrote: On Sep 19, 2015, at 5:25 AM, Rod Smallwood wrote: Is an overlay self modifyig code? Yes (#2 in my list), but a controlled kind so it doesn't suffer from the maintainability issues of explicitly modified instructions.

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 19 September 2015 at 17:02, Rod Smallwood wrote: > Its a while back but I seem to remember in BASIC you replaced a set of line > numbers with another of the same range but different code. Blimey, I've never seen that. I do remember that ZX BASIC had a

eval() considered dodgy - Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-19 1:15 PM, Liam Proven wrote: On 19 September 2015 at 17:02, Rod Smallwood wrote: Its a while back but I seem to remember in BASIC you replaced a set of line numbers with another of the same range but different code. Blimey, I've never seen that. I

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> > Its a while back but I seem to remember in BASIC you replaced a set of line > > numbers with another of the same range but different code. > > Blimey, I've never seen that. A lot of disk-based BASICs had a statement that would merge a program from disk in this way. Sometimes the program had

Re: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

On 18/09/15 14:31, Mouse wrote: | | The single exception is that we will not publish the list of "system | killers" outside of Digital. All questions about "system killers", | even ones asking if there are any, will be answered "No Comment". The | reason for this is to protect

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/18/2015 7:33 AM, tony duell wrote: Are there any computers that do let you put microcode into RAM now-days. "Now-days"? There are some that do that, some of which are still in operational shape. Some VAXen, in particular, have something called "writable control store", which is

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/18/2015 04:42 PM, Johnny Billquist wrote: The normal WCS option for the 11/780 was an option. Not everyone had it. Were there another option with some WCS that actually everybody had? I don't recall clearly whether our 780 (bought about 1980?) came with a small WCS or no WCS. I do

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> > > Simple answer. The control store functionality had to fit in the available > space > on one hex > sized card, and 16K density DRAM was the only option. Allocating additional > space to use > 4K or 1K SRAM would have pushed the CPU design to an additional board, which > was not > a design

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/18/2015 9:51 PM, tony duell wrote: The VAX-11/730 would have to have the microcode on TU58, as that is the console media. Quite possible that it actually do load the microcode from there at power up. I've heard that those machine were slow in so many ways... :-) The 11/730 has no microcode

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-18 15:45, tony duell wrote: As far as I know, the VAX11/730 (There is one next to me waiting for me to have time to restore it) has the microcode entirely in RAM. Classic PERQs (3 in the next room) have The PDP-11 console loads the microcode from disk then mostly just sits there

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-18 15:33, tony duell wrote: Are there any computers that do let you put microcode into RAM now-days. "Now-days"? There are some that do that, some of which are still in operational shape. Some VAXen, in particular, have something called "writable control store", which is

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-18 18:21, Jon Elson wrote: On 09/18/2015 08:45 AM, tony duell wrote: As far as I know, the VAX11/730 (There is one next to me waiting for me to have time to restore it) has the microcode entirely in RAM. Classic PERQs (3 in the next room) have The PDP-11 console loads the microcode

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-18 18:21, Eric Smith wrote: On Fri, Sep 18, 2015 at 7:45 AM, tony duell wrote: The 11/780 has a PDP11 to load the microcode (I think) but the 11/730 makes do with an 8085. After booting I think that handles the console port still. Most of the 11/780

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> Are there any computers that do let you put microcode into RAM > now-days. "Now-days"? There are some that do that, some of which are still in operational shape. Some VAXen, in particular, have something called "writable control store", which is essentially microcode RAM. > You have a lot of

Re: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

On 18 September 2015 at 13:35, Lars Brinkhoff wrote: > I believe the VIA C3 had an undocumented feature to allow executing the > underlying RISC instructions. [[Citation needed]] I've never heard of anything like this. Are you perhaps thinking of the Crusoe family chips? --

RE: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Liam > Proven > Sent: 18 September 2015 13:23 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk@classiccmp.org> > Subject: Re: OT: x86 machine code [Was: Re:

Re: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

On 18 September 2015 at 13:06, Pontus Pihlgren wrote: > I've been told this more than a few times and read it in various places. > It always make me wonder, could we not allow a mode in modern Intel > processors that lets us bypass the x86 code emulation/translation and > run

OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

On Fri, Sep 18, 2015 at 06:58:24AM -0400, Mouse wrote: > > > You have a lot of byte code virtual machines out there. > > Such as every x86 processor since, what, the Pentium? They're all RISC > cores (designed for and) running an x86 emulator. > I've been told this more than a few times and

Re: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

Pontus Pihlgren writes: > On Fri, Sep 18, 2015 at 06:58:24AM -0400, Mouse wrote: >> Such as every x86 processor since, what, the Pentium? They're all >> RISC cores (designed for and) running an x86 emulator. > > I've been told this more than a few times and read it in

RE: Self modifying code, lambda calculus - Re: ENIAC programming

"Self modifying code may seem like a neat idea. But, it will turn around and byte you in the arse. Maybe not now, but soon, and for the rest of your life."

Re: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

On 2015-09-18 7:06 AM, Pontus Pihlgren wrote: On Fri, Sep 18, 2015 at 06:58:24AM -0400, Mouse wrote: You have a lot of byte code virtual machines out there. Such as every x86 processor since, what, the Pentium? They're all RISC cores (designed for and) running an x86 emulator. I've been

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> > > Are there any computers that do let you put microcode into RAM > > now-days. > > "Now-days"? There are some that do that, some of which are still in > operational shape. Some VAXen, in particular, have something called > "writable control store", which is essentially microcode RAM. As

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of tony duell > Sent: 18 September 2015 14:33 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk@classiccmp.org> > Subject: RE: Self modifying code, lambda calculus

Re: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

>> Such as every x86 processor since, what, the Pentium? They're all >> RISC cores (designed for and) running an x86 emulator. > I've been told this more than a few times and read it in various > places. It always make me wonder, could we not allow a mode in > modern Intel processors that lets

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> > > > As far as I know, the VAX11/730 (There is one next to me waiting for me to > > have time > > to restore it) has the microcode entirely in RAM. Classic PERQs (3 in the > > next room) have > > The PDP-11 console loads the microcode from disk then mostly just sits there > looking pretty

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On Fri, Sep 18, 2015 at 7:45 AM, tony duell wrote: > The 11/780 has a PDP11 to load the microcode (I think) but the 11/730 makes > do with an > 8085. After booting I think that handles the console port still. Most of the 11/780 microcode is in bipolar PROM. There's a

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/18/2015 08:45 AM, tony duell wrote: As far as I know, the VAX11/730 (There is one next to me waiting for me to have time to restore it) has the microcode entirely in RAM. Classic PERQs (3 in the next room) have The PDP-11 console loads the microcode from disk then mostly just sits there

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/17/2015 11:19 PM, Guy Sotomayor wrote: On 9/17/15 8:55 PM, Jon Elson wrote: I think the later X86 machines have a tiny block of patch microcode that is available to the OS to put special routines into. Certainly not Intel CPUs. All of the microcode patches are loaded via special

Re: OT: x86 machine code [Was: Re: Self modifying code, lambda calculus - Re: ENIAC programming]

Just a quick history of x86 implementation styles (from memory, so don't take this very seriously): 8086: Intel's first pipeline, with separate Fetch and Execution units iAPX286: borrowed some ideas from iAPX432's protection model, but I don't know any implementation details 386: traditional

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> On Sep 16, 2015, at 11:36 PM, ben wrote: > > On 9/16/2015 9:25 PM, Toby Thain wrote: >> On 2015-09-16 6:18 PM, Dave G4UGM wrote: >>> >>> ... >>> It is notable that in order to solve all problems, a computer must permit >>> self modifying code. >> >> >> Is that true?

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Paul > Koning > Sent: 17 September 2015 17:02 > To: General Discussion: On-Topic and Off-Topic Posts > <cctalk@classiccmp.org> > Subject: Re: Self modifying code, lambda calcu

RE: Self modifying code, lambda calculus - Re: ENIAC programming

What is the definition of self modifying? Is it changing an instruction to execute in the thread to be run? How about adding or subtracting something to be done in an execution queue? I'm not sure there is a lot of difference. In the first case, one might leave the instruction for a later

Re: Self modifying code, lambda calculus - Re: ENIAC programming

I took it from Crispin's paper and I assumed it was correct as he has done a lot of work on this... .. and I assumed when he said "solve all problems" we were referring to problems that can be solved on a Turing Complete computer It is easy to prove that a computer does not need the

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> On Sep 17, 2015, at 2:56 PM, dwight wrote: > > What is the definition of self modifying? > Is it changing an instruction to execute in the thread to be run? > How about adding or subtracting something to be done in an execution > queue? I'm not sure if there is a

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> On Sep 17, 2015, at 3:27 PM, Paul Koning wrote: > > >> On Sep 17, 2015, at 2:56 PM, dwight wrote: >> >> What is the definition of self modifying? >> Is it changing an instruction to execute in the thread to be run? >> How about adding or

RE: Self modifying code, lambda calculus - Re: ENIAC programming

I am quite aware of the caching problem. What I don't understand is what problem they thought they were fixing by outlawing self modifying code. It exist in so many forms that are not as obvious. All of which can have the same potential problems. The note about 8080 I/O's brought back memories of

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> On Sep 17, 2015, at 5:52 PM, Jay Jaeger wrote: > > On 9/17/2015 2:27 PM, Paul Koning wrote: >> >>> On Sep 17, 2015, at 2:56 PM, dwight wrote: >>> >>> What is the definition of self modifying? >>> Is it changing an instruction to execute in the thread

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> On Sep 17, 2015, at 5:42 PM, dwight wrote: > > I am quite aware of the caching problem. > What I don't understand is what problem they thought they > were fixing by outlawing self modifying code. Self modifying code in sense #4 from my earlier note (i.e., a program that

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/17/2015 6:50 PM, Jecel Assumpcao Jr. wrote: This conclusion should have been obvious to anyone thinking about general purpose computers implemented with microcode in ROM. Are there any computers that do let you put microcode into RAM now-days. You have a lot of byte code virtual

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-18 01:29, Dave G4UGM wrote: -Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Johnny Billquist Sent: 18 September 2015 00:12 To: cctalk@classiccmp.org Subject: Re: Self modifying code, lambda calculus - Re: ENIAC programming On 2015-09-17

Re: Self modifying code, lambda calculus - Re: ENIAC programming

> What I don't understand is what problem they thought they were fixing > by outlawing self modifying code. As the discussion illustrates, and as I point out below, in some of the weaker senses it's still alive and well, not outlawed at all. In the usual sense, approximately "code which writes

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-17 18:30, Dave G4UGM wrote: -Original Message- From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Paul Koning Sent: 17 September 2015 17:02 To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org> Subject: Re: Self modifying code,

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 2015-09-17 18:01, Paul Koning wrote: On Sep 16, 2015, at 11:36 PM, ben wrote: On 9/16/2015 9:25 PM, Toby Thain wrote: On 2015-09-16 6:18 PM, Dave G4UGM wrote: ... It is notable that in order to solve all problems, a computer must permit self modifying code.

RE: Self modifying code, lambda calculus - Re: ENIAC programming

> -Original Message- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Johnny > Billquist > Sent: 18 September 2015 00:12 > To: cctalk@classiccmp.org > Subject: Re: Self modifying code, lambda calculus - Re: ENIAC programming > > On 2015-09-17

RE: Self modifying code, lambda calculus - Re: ENIAC programming

From: Paul Koning Sent: Thursday, September 17, 2015 9:02 AM > In any case, I do not believe the original statement. First of all, it is > well known that no computer can solve "all problems" (see Gödel). For those > it *can* solve, as far as I know, a Turing machine can solve a superset of >

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 09/17/2015 08:40 PM, ben wrote: On 9/17/2015 6:50 PM, Jecel Assumpcao Jr. wrote: This conclusion should have been obvious to anyone thinking about general purpose computers implemented with microcode in ROM. Are there any computers that do let you put microcode into RAM now-days. You

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/17/15 8:55 PM, Jon Elson wrote: I think the later X86 machines have a tiny block of patch microcode that is available to the OS to put special routines into. Certainly not Intel CPUs. All of the microcode patches are loaded via special instruction sequences (described in the SDM).

Re: Self modifying code, lambda calculus - Re: ENIAC programming

On 9/16/2015 9:25 PM, Toby Thain wrote: On 2015-09-16 6:18 PM, Dave G4UGM wrote: ... It is notable that in order to solve all problems, a computer must permit self modifying code. Is that true? AFAIK Lambda calculus can describe any computable function (as can a Turing machine), and it has