From: "Martin Ward"
Sent: Saturday, February 03, 2018 6:40 AM
On 02/02/18 19:03, Paul Gilmartin wrote:
On 2018-02-02, at 06:28:54, Martin Ward wrote:
The original Pascal string used a single byte for the length
at a time when a $70K machine had a mere 4K words of memory.
I don't recall see
On Fri, 2 Feb 2018 19:40:41 +, Martin Ward wrote:
>A typical CDC 6500 had 64K of 60 bit words (about 500kB)
>and cost over $60 million in 2017 dollars. I suspect that
>today $60 million will buy you a machine with over 500GB of RAM,
>so the million-to-one ratio still holds.
I'd be surprised i
Am 04.02.2018 um 01:28 schrieb Paul Raulerson:
Well, that was fairly easy. :) Just a few warnings, but the executable
executes!
-Paul
Now please take a look at the (Windows) scripts PP.CMD
and PRUN.CMD; PP.CMD is used to run the compiler, and PRUN.CMD
is used to run the compiled Pascal p
> On Feb 3, 2018, at 1:26 AM, Bernd Oppolzer wrote:
>
> Thank you very much !
>
> A friend called Rene Jansen tried the compiler in May 2017
> on modern z/OS and MacOS, look here:
>
> http://bernd-oppolzer.de/job9i040.htm
>
> it worked without problems; only for MacOS we had to make a minor
>
Am 03.02.2018 um 17:29 schrieb Paul Gilmartin:
On 2018-02-03, at 00:26:47, Bernd Oppolzer wrote:
A friend called Rene Jansen tried the compiler in May 2017
on modern z/OS and MacOS, look here:
http://bernd-oppolzer.de/job9i040.htm
it worked without problems; only for MacOS we had to make a min
On 2018-02-03, at 00:26:47, Bernd Oppolzer wrote:
>
> A friend called Rene Jansen tried the compiler in May 2017
> on modern z/OS and MacOS, look here:
>
> http://bernd-oppolzer.de/job9i040.htm
>
> it worked without problems; only for MacOS we had to make a minor
> change, because colons in envi
Thank you very much !
A friend called Rene Jansen tried the compiler in May 2017
on modern z/OS and MacOS, look here:
http://bernd-oppolzer.de/job9i040.htm
it worked without problems; only for MacOS we had to make a minor
change, because colons in environment variable names are not allowed.
I
I have to say, that is just dang *cool*. I loved reading your page. You sir,
are damned impressive!
Let me know if you get a Mac version working please. :)
-Paul
> On Feb 2, 2018, at 3:24 AM, Bernd Oppolzer wrote:
>
> Because of this topic drift, I'd like to inform you, that I
> recentl
> On Feb 2, 2018, at 1:03 PM, Paul Gilmartin
> <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote:
>
> On 2018-02-02, at 02:24:51, Bernd Oppolzer wrote:
>>
>> My string implementation uses two length fields in front of every string,
>> the first being the maxlength field, which tells the ma
On 02/02/18 19:03, Paul Gilmartin wrote:
On 2018-02-02, at 06:28:54, Martin Ward wrote:
The original Pascal string used a single byte for the length
at a time when a $70K machine had a mere 4K words of memory.
I don't recall seeing that in Wirth's Pascal User Manual and Report,
which I conside
On 2018-02-02, at 02:24:51, Bernd Oppolzer wrote:
>
> My string implementation uses two length fields in front of every string,
> the first being the maxlength field, which tells the maximum length that the
> string can hold, and the second one is the actual length, which obviously
> should
> be
Mainframe Assembler List on behalf
of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, February 2, 2018 11:58 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Pascal
On 2018-02-02, at 09:32:08, Seymour J Metz wrote:
> I prefer the PL/I solution, does not s
On 2018-02-02, at 09:32:08, Seymour J Metz wrote:
> I prefer the PL/I solution, does not specify how they are implementedrr,
> only how they behave. Other languages, e.g., Icon, Perl, do the same thig.
>
But it matters greatly in interfaces to other languages.
-- gil
of Rob van der Heij
Sent: Friday, February 2, 2018 9:41 AM
To: ASSEMBLER-LIST@listserv.uga.edu
Subject: Re: Pascal
On 2 February 2018 at 14:28, Martin Ward wrote:
>
> Incidentally, perl strings can be over 4GB in length: in fact,
> any size which will will fit in memory (including s
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Rob van der Heij
> Sent: 02 February 2018 14:42
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: Pascal
>
> On 2 February 2018 at 1
On 2 February 2018 at 14:28, Martin Ward wrote:
>
> Incidentally, perl strings can be over 4GB in length: in fact,
> any size which will will fit in memory (including swap space).
>
Just don't let the ASN.1 folks come closer, or you end up with variable
length length fields... ;-)
I would think
are an employee) is the owner.
Charles
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of John McKown
Sent: Friday, February 2, 2018 5:38 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Pascal
On Fri, Feb 2, 2018 at 7:32 AM,
Am 02.02.2018 um 14:28 schrieb Martin Ward:
On 02/02/18 09:24, Bernd Oppolzer wrote:
My string implementation uses two length fields in front of every
string, the first being the maxlength field, which tells the maximum
length that the string can hold, and the second one is the actual
length, wh
On Fri, Feb 2, 2018 at 7:32 AM, Bernd Oppolzer
wrote:
> I didn't care much about license so far;
> the code is available for free from the links mentioned below.
> See also here:
>
FSVO "free". If you don't assign a license, then I would think (I'm not a
lawyer) that the Berne Copyright convent
I didn't care much about license so far;
the code is available for free from the links mentioned below.
See also here:
https://github.com/StanfordPascal/Pascal
this will be most recent, my actual development version.
I deploy the compiler to the MVSINST subdirectory (and zip file,
which can be dow
On 02/02/18 09:24, Bernd Oppolzer wrote:
My string implementation uses two length fields in front of every
string, the first being the maxlength field, which tells the maximum
length that the string can hold, and the second one is the actual
length, which obviously should be less or equal to the
What license is this code released under?
On Fri, Feb 2, 2018 at 3:24 AM, Bernd Oppolzer
wrote:
> Because of this topic drift, I'd like to inform you, that I
> recently added strings to my version of the Stanford Pascal compiler,
> which is a descendent of the Wirth Pascal P4 compiler.
>
> My st
From: "IBM Mainframe Assembler List"
To:
Cc:
Sent:Fri, 2 Feb 2018 00:49:57 -0600
Subject:Re: Pascal (was : comparison C vs HLASM)
> On Feb 1, 2018, at 9:13 PM, Robin Vowels
wrote:
>
>> From: "Paul Gilmartin"
<0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
>> Sent: Friday, February 02, 20
Because of this topic drift, I'd like to inform you, that I
recently added strings to my version of the Stanford Pascal compiler,
which is a descendent of the Wirth Pascal P4 compiler.
My string implementation uses two length fields in front of every string,
the first being the maxlength field, w
> On Feb 1, 2018, at 9:13 PM, Robin Vowels wrote:
>
> From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
> Sent: Friday, February 02, 2018 2:16 AM
>
>
> On 2018-02-01, at 06:55:29, Paul Raulerson wrote:
>>
>> It also explains one of the reasons why strings in C are null t
From: "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu>
Sent: Friday, February 02, 2018 2:16 AM
On 2018-02-01, at 06:55:29, Paul Raulerson wrote:
It also explains one of the reasons why strings in C are null terminated. There were two modes of
thought back in those days, ‘Pas
26 matches
Mail list logo
