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
s
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
buil
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
langu
> 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
build a p-code engine in FORTRAN and i
On 09/21/2015 04:58 PM, Al Kossow wrote:
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
It's COMPASS all right, but a quick scan t
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
On Mon, 21 Sep 2015, Chuck Guzis wrote:
PASCAL was first implemented in FORTRAN.
But then, much later, . . .
Microsoft/IBM PC Pascal was written by Bob Wallace.
I have no idea WHO, but Microsoft/IBM PC FORTRAN was written in Microsoft
Pascal. There was an odd little warning not to use any 6
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 o
> 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 strings with matching i
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 hav
> -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
>
> Subject: Re: Self modifying code, lambda calculus - Re: ENIAC programmi
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 li
[...] 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 pr
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 langu
> [...] 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?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML
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 overlay
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
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 RU
On Sun, 20 Sep 2015 at 16:47:50 +0200 Liam Proven wrote:
> 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 p
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, some could
> get
> overw
On 20/09/2015 11:52, Liam Proven wrote:
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
>
> 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) vari
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: http://lproven.livejournal.com/profile
Email: lpro...@ci
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 if you were typing
> it on
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.
> > 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
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 do remember that ZX BASIC had a
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 cool-but-dangerous feature: you
could get
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. But it does
require I-cache man
> 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 management, if the computer has an I-c
>
> The biggest risk I remember from the 730 design (I worked in the same hardware
> lab, different project: 11/74 CIS) was the extensive use of PALs. This was the
> first (I believe) project at DEC to use them, and they were basically buying
> all
It may well have been. Certainly the 11/730 is
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 essentiall
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, whic
>
>
> 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
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
> 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 ROM as far as I can see. However p
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 rem
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 cust
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 microcode is in bipolar PROM. T
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 f
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
l
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 essentia
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 essenti
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 CIS
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
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 small patch
area which is lo
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 i
"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."
> >
> > 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 whi
On Fri, Sep 18, 2015 at 01:33:05PM +, 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 calle
> -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
>
> Subject: 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 u
>
> > 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 fa
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
> -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
>
> Subject: Re: OT: x86 machine code [Was: Re: Self modifying code, lambda
&
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?
--
Liam Proven • Prof
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 "directly on the meta
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 various places.
> It always
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
> 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
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). T
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
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 machines
> 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
scribbles on bits of
> 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 to be run?
>>> How about adding or subtr
Rich Alderson on Thu, 17 Sep 2015 23:49:59 + wrote:
> 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* so
> 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 me
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
> wh
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
> -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
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.
Is that true? AFAIK Lambda
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
Subject: Re: Self modifying code, lambda calculus - Re: ENIAC
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 to be run?
>> How about adding or subtracting something to be done in an execution
>> queue?
>
> I'm
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
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?
What he said. In the narrow viewpoint, "self-modifying" could be
> 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 subtracting something to be done in an execution
>> q
> 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 universally agreed to definit
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 execution
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
> -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
>
> Subject: Re: Self modifying code, lambda calculus - Re: ENIAC programmin
> 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? AFAIK Lambda calculus ca
#d
I found it interesting...
Dave Wade
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of ben
> Sent: 17 September 2015 04:37
> To: cctalk@classiccmp.org
> Subject: Re: Self modifying code, lambda calculus - Re: ENIAC programming
>
> On 9
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 n
83 matches
Mail list logo
