ENIAC programming Was: release dates of early microcomputer operating systems, incl. Intel ISIS
17 Sep
2015
17 Sep
'15
8:39 a.m.
From: Dave Wade
Crispin Rope concentrates on the power of ENIAC and
its usefulness
Which is why you should look at the longer, later article:
http://eniacinaction.com/wp-content/uploads/2014/02/EngineeringTheMiracleof…
in particular the part I pointed out (bottom right corner of pg. 51), which
talks about all the things that can be found in that early ENIAC code, e.g.
subroutine calls with storage of return point, etc.
I am far less interested in the comparison with other machines (in that
article) than I am with the enumeration of what the 'program ENIAC' _itself_
could do - which seems to have been quite a lot.
to me a "computer" without self-modifying
code is a programmable
calculator even if it has index registers...
So a modern Harvard-architecture machine (e.g. AMD29K) with only ROM on the
instruction bus is a programmable calculator?
It's precisely that hypothetical which leads me to conclude that the fact
that the 'program ENIAC' only had ROM for its code (actually, technically,
that's quite not true - it could execute programs stored on cards, too) is
not that important; I think the thing to look at is what its programs could
contain.
Noel
17 Sep
17 Sep
12:44 p.m.
From: Dave
Wade
to me a "computer" without
self-modifying code is a programmable
calculator even if it has index registers...
1:29 p.m.
New subject: Immutability - was Re: ENIAC programming Was: release dates of early microcomputer operating systems, incl. Intel ISIS
On 2015-09-17 12:44 PM, Jon Elson wrote:
Most modern computer languages run with the executable instructions in a
"pure code" section, which is set to be NOT writeable by the program.
This avoids a LOT of simple mistakes and REALLY hard to find program
crashes.
This is true of MS, Linux/Unix and the VMS program environment that I
have used for about 40 years. I think you have to go back to maybe
Windows 95 or RT-11 to not have that protection.
Modern languages extend this "protection" further, to the programmer
model, with immutable bindings and data structures, shunning variables
entirely.
--Toby
From:
Dave Wade
to me a "computer" without
self-modifying code is a programmable
calculator even if it has index registers...
Jon
5:31 p.m.
New subject: Immutability - was Re: ENIAC programming Was: release dates of early microcomputer operating systems, incl. Intel ISIS
Date: Thu, 17 Sep 2015 13:29:34 -0400
From: toby at telegraphics.com.au
To: General at classiccmp.org; classiccmp.org:On-Topic and Off-Topic Posts cctalk at
classiccmp.org; General at classiccmp.org
Subject: Immutability - was Re: ENIAC programming Was: release dates of early
microcomputer operating systems, incl. Intel ISIS
On 2015-09-17 12:44 PM, Jon Elson wrote:
Most modern computer languages run with the executable instructions in a
"pure code" section, which is set to be NOT writeable by the program.
This avoids a LOT of simple mistakes and REALLY hard to find program
crashes.
This is true of MS, Linux/Unix and the VMS program environment that I
have used for about 40 years. I think you have to go back to maybe
Windows 95 or RT-11 to not have that protection.
Modern languages extend this "protection" further, to the programmer
model, with immutable bindings and data structures, shunning variables
entirely.
--Toby
If working on a newer X86 processor, this is necessary, not to protect the
code but because the code is cashed and my not be updated in time for
it to be executed.
Write through is expensive and only provided on the data side, if at all.
Dwight
From:
Dave Wade
to me a "computer" without
self-modifying code is a programmable
calculator even if it has index registers...
Jon
5:38 p.m.
New subject: Immutability - was Re: ENIAC programming Was: release dates of early microcomputer operating systems, incl. Intel ISIS
On Thu, 17 Sep 2015, dwight wrote:
If working on a newer X86 processor, this is
necessary, not to protect the
code but because the code is cashed and my not be updated in time for
it to be executed.
Write through is expensive and only provided on the data side, if at all.
Dwight
On some/most older X86 real mode, a JMP $+2 would flush the prefetch
buffer, and make possible some simple self-modifying code (such as
changing the second byte of an INT instruction)
19 Sep
19 Sep
3:07 a.m.
New subject: Immutability - was Re: ENIAC programming Was: release dates of early microcomputer operating systems, incl. Intel ISIS
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Toby
Thain
Sent: 17 September 2015 18:30
To: General at classiccmp.org; Discussion at classiccmp.org:On-Topic and Off-
Topic Posts <cctalk at classiccmp.org>; General at classiccmp.org
Subject: Immutability - was Re: ENIAC programming Was: release dates of
early microcomputer operating systems, incl. Intel ISIS
On 2015-09-17 12:44 PM, Jon Elson wrote:
>
>> > From: Dave Wade
>>
>>
>> > to me a "computer" without self-modifying code is a
programmable
>> > calculator even if it has index registers...
>>
>>
> Most modern computer languages run with the executable instructions in
> a "pure code" section, which is set to be NOT writeable by the program.
> This avoids a LOT of simple mistakes and REALLY hard to find program
> crashes.
> This is true of MS, Linux/Unix and the VMS program environment that I
> have used for about 40 years. I think you have to go back to maybe
> Windows 95 or RT-11 to not have that protection.
Actually not (quite). The true virtual machines in NT builds of Windows and
Linux protect programs from each other. So you can't damage someone else's
code...
but I believe that you could still load code into the data area and execute
it.. up until about 10 years ago when DEP was introduced....
http://malwaremusings.com/2012/10/13/self-modifying-code-changing-memory-pro
tection/
and if your code is running with admin rights on Windows you can use the
"VirtualProtect" interface to allow you to write self-modifying code.....
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366898(v=vs.85).a
spx
Of course this is part of the reason we have all these problems with Buffer
Overrun.....
Modern languages extend this "protection" further, to the programmer
model, with immutable bindings and data structures, shunning variables
entirely.
--Toby
>
> Jon
>
Dave
17 Sep
17 Sep
1:33 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Jon Elson
Sent: 17 September 2015 17:44
To: General at classiccmp.org; Discussion at classiccmp.org:On-Topic and Off-
Topic Posts <cctalk at classiccmp.org>
Subject: Re: ENIAC programming Was: release dates of early microcomputer
operating systems, incl. Intel ISIS
Most modern computer languages run with the executable instructions in a
"pure code" section, which is set to be NOT writeable by the program.
This
From:
Dave Wade
to me a "computer" without
self-modifying code is a programmable
calculator even if it has index registers...
avoids a LOT of simple mistakes and REALLY hard to
find program crashes.
This is true of MS, Linux/Unix and the VMS program environment that I have
used for about 40 years. I think you have to go back to maybe Windows 95
or
RT-11 to not have that protection.
Windows/ME was the last program not to have that protection, but it is just
that, protection. At certain points in the execution process masks are set
to prevent programs from modifying themselves, at a macro level the system
has the capability to modify instructions, in the general case if the system
is considered a program, then it applies protections to prevent subsets of
code doing this....
Jon
12:47 p.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Noel
Chiappa
Sent: 17 September 2015 13:39
To: cctalk at classiccmp.org
Cc: jnc at mercury.lcs.mit.edu
Subject: Re: ENIAC programming Was: release dates of early microcomputer
operating systems, incl. Intel ISIS
Thanks Noel, I will have a browse of that...
From: Dave Wade
Crispin Rope concentrates on the power of ENIAC
and its usefulness
Which is why you should look at the longer, later article:
http://eniacinaction.com/wp-
content/uploads/2014/02/EngineeringTheMiracleoftheENIAC-scanned.pdf
in particular the part I pointed out (bottom right
corner of pg. 51),
which talks
about all the things that can be found in that early
ENIAC code, e.g.
subroutine calls with storage of return point, etc.
I am far less interested in the comparison with other machines (in that
article) than I am with the enumeration of what the 'program ENIAC'
_itself_
could do - which seems to have been quite a lot.
AMD29K isn't "Modern", but when used like that it's a programmable
calculator, a very sophisticated one yes......
... If you have to use another external mechanism to arbitrarily change the
program, then it's a calculator.....
.. So a PIC chip for example.....
Where It gets grey is that a Turing machine gets round this by assuming the
tape has infinite length.
I think (but am not sure) is that in effect whilst you can't have self
modifying code you have enough storage for all possible programs...
to me a "computer" without
self-modifying code is a programmable
calculator even if it has index registers...
So a modern Harvard-architecture machine (e.g. AMD29K) with only ROM on
the instruction bus is a programmable calculator?
It's precisely that hypothetical which leads me to conclude that the fact
that
the 'program ENIAC' only had ROM for its code
(actually, technically,
that's
quite not true - it could execute programs stored on
cards, too) is not
that
important; I think the thing to look at is what its
programs could contain
I think the important things end up being hypothetical, Its more WHY was it
designed so its programs COULD contain what they could contain..
Noel
Dave
3230
days inactive
3232
days old
7 comments
6 participants
participants (6)
-
cisin＠xenosoft.com -
dave.g4ugm＠gmail.com -
dkelvey＠hotmail.com -
elson＠pico-systems.com -
jnc＠mercury.lcs.mit.edu -
toby＠telegraphics.com.au