On 2013-01-15 18:33, Clem Cole wrote:
On Tue, Jan 15, 2013 at 12:05 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Right. I'm sure that with enough work, you can always do it, but I'm
curious on how much work. I have a feeling that compilers written in
high level languages rapidly expand their requirements...
Its not that actually - IMHO. You can always use overlays and thunks
to write code that works on a small address machines, like the PDP-11.
I think the problem is that people that used / wanted the language did
not need all of the features and frankly time moved on. The languages
themselves were just too heavy not the compiler per say - the compilers
became heavy to support the language features people wanted.
If PL/M or PL/360 had not lost to C (BCPL et al), it might have been
different in the case of PL/1. If you note sub-set C compilers for the
8 and 16 bit machines exist or often exist as cross compilers from
larger systems.
The issue is that 16-bits of data space is >>very<< limiting for a
programmer, the code space can be swapped in and out with automatic or
managed overlays - but data space is much harder to do.
But I'm not talking about cross compilers or subsets. That is a totally different topic. I guess you are arguing that PL/1 is still PL/1, and is not heavy because it's old and not so full of features.
That is probably true in itself, but I still suspect that the requirements of a PL/1 compiler written in PL/1 are much higher than a PL/1 compiler written in assembler.
The DEC PDP-11 C compiler is not a subset, but is a pretty complete ANSI C. And it is not a cross compiler. But the requirements of the compiler is high, and the code it produces aren't that great.
The FORTRAN 77 compiler, as a comparison, produces much better code, and do lots of more optimizations. Heck, even the DECUS C produces better code (that is, when it actually manage to compile anything at all, it's a very retro K&R C implementation).
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-01-15 18:19, Clem Cole wrote:
On Tue, Jan 15, 2013 at 12:05 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
I don't think it was, but It's hard to say, as it's just one big
binary blob to me. However, would the GEM even fit on a PDP-11?
It would not easily self host, but few of the PDP-11 compilers were
asked to self host. They started cross compiling from the 10's then
from the Vaxen. By the time PDP-11 went EOL, the cross compilers were
running on Alpha (and maybe PMAX - again too man beers ago).
The the DEC PDP-11 C runs on the PDP-11, it's not a cross compiler.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Erik Olofsen <e.olofsen at xs4all.nl> writes:
Perhaps we could compare dumps of various monitor.exes.
The command procedure actually opens up three more classes: VMS1, VMS2,
and VMS3; their output follows for interested readers; but unfortunately
on my system no items seem to be reserved :)
VAX/VMS Monitor Utility
VMS DEVELOPMENT 1 on node
RULLFS 15-JAN-2013 21:13:53
CUR AVE MIN
MAX
FCP Call Rate 0.00 0.00 0.00
0.00
Volume Lock Req. Rate 0.00 0.00 0.00
0.00
Volume Lock Wait Rate 0.00 0.00 0.00
0.00
Other Sync Lock Req. Rate 0.00 0.00 0.00
0.00
Other Sync Lock Wait Rate 0.00 0.00 0.00
0.00
Access Lock Req. Rate 0.00 0.00 0.00
0.00
Cache Wait Rate 0.00 0.00 0.00
0.00
FYI, FCP is now a recognised class in MONITOR.
The MONITOR command initiates monitoring of statistics for the
classes of information you specify.
Format
MONITOR [/command qualifier[,...]] classname[,...] [/classname
qualifier[,...]]
Additional information available:
Parameter Command_Qualifier_Descriptions
/BEGINNING /BY_NODE /COMMENT /DISPLAY /ENDING /FLUSH_INTERVAL
/INPUT /INTERVAL /NODE /OUTPUT /RECORD /SUMMARY
/VIEWING_TIME
ALL_CLASSES CLUSTER DECNET DISK DLOCK FCP
FILE_SYSTEM_CACHE IO LOCK MODES MSCP_SERVER
PAGE PROCESSES RLOCK RMS SCS STATES SYSTEM
TIMER TRANSACTION VBS VECTOR
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
Perhaps we could compare dumps of various monitor.exes.
The command procedure actually opens up three more classes:
VMS1, VMS2, and VMS3; their output follows for interested readers;
but unfortunately on my system no items seem to be reserved :)
VAX/VMS Monitor Utility
VMS DEVELOPMENT 1
on node RULLFS
15-JAN-2013 21:13:53
CUR AVE MIN MAX
FCP Call Rate 0.00 0.00 0.00 0.00
Volume Lock Req. Rate 0.00 0.00 0.00 0.00
Volume Lock Wait Rate 0.00 0.00 0.00 0.00
Other Sync Lock Req. Rate 0.00 0.00 0.00 0.00
Other Sync Lock Wait Rate 0.00 0.00 0.00 0.00
Access Lock Req. Rate 0.00 0.00 0.00 0.00
Cache Wait Rate 0.00 0.00 0.00 0.00
VAX/VMS Monitor Utility
VMS2 STATISTICS
on node RULLFS
15-JAN-2013 21:16:56
CUR AVE MIN MAX
Reserved Item 1 Rate 0.00 0.00 0.00 0.00
Reserved Item 2 Rate 0.00 0.00 0.00 0.00
Reserved Item 3 Rate 0.00 0.00 0.00 0.00
Reserved Item 4 Rate 0.00 0.00 0.00 0.00
Reserved Item 5 Rate 0.00 0.00 0.00 0.00
Reserved Item 6 Rate 0.00 0.00 0.00 0.00
Reserved Item 7 Rate 0.00 0.00 0.00 0.00
Reserved Item 8 Rate 0.00 0.00 0.00 0.00
Reserved Item 9 Rate 0.00 0.00 0.00 0.00
VAX/VMS Monitor Utility
VMS3 STATISTICS
on node RULLFS
15-JAN-2013 21:17:14
CUR AVE MIN MAX
Reserved Item 10 Rate 0.00 0.00 0.00 0.00
Reserved Item 11 Rate 0.00 0.00 0.00 0.00
Reserved Item 12 Rate 0.00 0.00 0.00 0.00
Reserved Item 13 Rate 0.00 0.00 0.00 0.00
Reserved Item 14 Rate 0.00 0.00 0.00 0.00
Reserved Item 15 Rate 0.00 0.00 0.00 0.00
Reserved Item 16 Rate 0.00 0.00 0.00 0.00
Reserved Item 17 0.00 0.00 0.00 0.00
Reserved Item 18 0.00 0.00 0.00 0.00
On Tue, Jan 15, 2013 at 02:13:08PM -0500, Dave McGuire wrote:
Nice! That command procedure's comments say that it only works on
specific releases of VAX/VMS, namely 5.0, 5.1, 5.2, 5.4-2, 5.5, 6.0, and
6.1. Does anyone know if it works on (say) 7.3 as well? I'm guessing
no, due to the nature of the version-specific changes.
-Dave
On 01/14/2013 01:54 PM, Erik Olofsen wrote:
And the result:
VAX/VMS Monitor Utility
ETHERNET STATISTICS
on node RULLFS
14-JAN-2013 19:54:12
CUR AVE MIN MAX
Packets/second 20.59 28.87 12.95 85.04
Kbytes/second 2.65 3.66 1.99 8.63
Packet size 121.00 140.10 102.00 169.00
Multicast Packets/second 4.31 5.61 3.65 8.27
Multicast Kbytes/second 0.33 0.66 0.32 1.32
Multicast Packet size 108.00 119.80 90.00 196.00
Trans Single Collision 0.00 0.00 0.00 0.00
Trans Multiple Collision 0.00 0.00 0.00 0.00
Trans Initially Deferred 0.00 0.00 0.00 0.00
Internal Buffer Error 0.00 0.00 0.00 0.00
Local Buffer Error 0.00 0.00 0.00 0.00
Buffer Unavailable 0.00 0.00 0.00 0.00
On Mon, Jan 14, 2013 at 07:29:01PM +0100, Erik Olofsen wrote:
With Google I found:
https://mail.encompasserve.org/anon/htnotes/note?f1=VMS&f2=2314.0
Erik
On Mon, Jan 14, 2013 at 05:54:54PM +0000, lee.gleason at comcast.net wrote:
I get:
$ patch monitor.exe
PATCH Version 5-05 20-June-1991
%PATCH-I-NOLCL, image does not contain local symbols
%PATCH-I-NOGBL, some or all global symbols not accessible
PATCH>exam 4158+33e
00004496: 00000000
Erik
The addresses of the structures changed for each version or so of VMS...you'd need to locate them with the fiche, or reading a dump of the image, or , for older versions of VMS, just using the Google to find one for your version. I enclosed that one just as an example of what gets patched.
Lessee....I also recall that MON ETHERNET required PHY_IO privilege, and needed a logical name NI$DEVICE set to be your network adapter's name to work.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
--
Dave McGuire, AK4HZ
New Kensington, PA
TITAAN (44.35) is back on line.
AXP/VMS kits and VAX/VMS kits are added, in
TITAAN::DISK$AXPKITS:[AXPVMSnnn] and TITAAN::DISK$VAXKITS:[VAXVMSnnn]
The ISO files will be available in zip-ed formats eventually.
Hans
Mark - that is the theory, but in practice it is not going to tell you much that you can really take to the bank. Why? Because Whetstone is a poor benchmark -- the results vary too much depending on compiler, language implementation, architecture etc -- its too easy to game. please do some goggling -- around 1985 it fell out of favor because it as so meaningless.
John Mashey (then late of PWB and at the time ??CTO?? of MIPS) wrote a great piece which he cribbed the name from Benjamin Disraeli called: "Lies, Damned Lies and Benchmarks" - IIRC whetstone was one of the benchmarks he rips apart in that paper. John and others really set out to create a set of benchmarks that could work regardless of compiler and architecture that told you something reasonable about the system. That group would form SPEC.
So, if you really want to do this type of analysis, I think for the effort you suggesting, it be worth the extra time to dig up a copy of specint and run that not whetstone. What is cool is that all the manufacturers published their spec numbers so you can see what you should expect and what you get so you'll have real base line and be able to make some more direct inferences.
Clem
On Tue, Jan 15, 2013 at 1:44 PM, Mark Benson <md.benson at gmail.com> wrote:
On 15 Jan 2013, at 01:41, sampsa at mac.com wrote:
> Somebody was asking for a better benchmark than VUPS earlier, I found WHETSTONE.C on GORVAX which calculates MIPS. Not sure how much better it is than VUPS.COM, but here are some results:
>
> GORVAX (SIMH VAX, on a Core i5)
> Loops: 1000, Iterations: 1, Duration: 5 sec.
> C Converted Double Precision Whetstones: 20.0 MIPS
>
> CHIMPY (DS10)
> Loops: 10000, Iterations: 1, Duration: 2 sec.
> C Converted Double Precision Whetstones: 500.0 MIPS
>
> RHESUS (rx2600)
> Loops: 100000, Iterations: 1, Duration: 4 sec.
> C Converted Double Precision Whetstones: 2500.0 MIPS
>
> I've attached the C source to this message, and will put binaries for all three platforms as well as the source in RHESUS::[.MEDIALIB.WHETSTONE]
The cool thing about this is is compiles on other platforms, so we can do cool stuff like:
- Compare the available MIPS inside an emulator to the available MIPS on the host OS, giving a MIPS:MIPS ratio for emulator code
- Compare directly the power of older CPUs with newer ones and also derive ap erformance MIPS/Watt figure for various systems.
- Find out how incredibly CPUs have advanced in 50 years!
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
On Tue, 15 Jan 2013, Dave McGuire wrote:
On 01/15/2013 11:58 AM, Paul_Koning at Dell.com wrote:
If I remember right, PDP-11 Algol has been mentioned on this list
from time to time. That was released via DECUS, and I've seen those
bits in the past. The problem always was that the runtime code
(algol.rts) showed up only as a binary, no sources.
It looks like I have a copy of the sources. Would there be interest
in that? This is for RSTS (as a runtime system) though the I/O is
pretty simple and could presumably be adjusted for some other OS if
anyone wants to.
I'd love to play with this!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Paul, you know you can always hang stuff on RSTS.ORG if you'd like. You
should probably have a page here anyway.
Brett
Dave McGuire <mcguire at neurotica.com> writes:
Nice! That command procedure's comments say that it only works on
specific releases of VAX/VMS, namely 5.0, 5.1, 5.2, 5.4-2, 5.5, 6.0, and
6.1. Does anyone know if it works on (say) 7.3 as well? I'm guessing
no, due to the nature of the version-specific changes.
With the appropriate offsets for the patching, sure. A quick source
perusal show show that.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On 01/15/2013 11:58 AM, Paul_Koning at Dell.com wrote:
If I remember right, PDP-11 Algol has been mentioned on this list
from time to time. That was released via DECUS, and I've seen those
bits in the past. The problem always was that the runtime code
(algol.rts) showed up only as a binary, no sources.
It looks like I have a copy of the sources. Would there be interest
in that? This is for RSTS (as a runtime system) though the I/O is
pretty simple and could presumably be adjusted for some other OS if
anyone wants to.
I'd love to play with this!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Nice! That command procedure's comments say that it only works on
specific releases of VAX/VMS, namely 5.0, 5.1, 5.2, 5.4-2, 5.5, 6.0, and
6.1. Does anyone know if it works on (say) 7.3 as well? I'm guessing
no, due to the nature of the version-specific changes.
-Dave
On 01/14/2013 01:54 PM, Erik Olofsen wrote:
And the result:
VAX/VMS Monitor Utility
ETHERNET STATISTICS
on node RULLFS
14-JAN-2013 19:54:12
CUR AVE MIN MAX
Packets/second 20.59 28.87 12.95 85.04
Kbytes/second 2.65 3.66 1.99 8.63
Packet size 121.00 140.10 102.00 169.00
Multicast Packets/second 4.31 5.61 3.65 8.27
Multicast Kbytes/second 0.33 0.66 0.32 1.32
Multicast Packet size 108.00 119.80 90.00 196.00
Trans Single Collision 0.00 0.00 0.00 0.00
Trans Multiple Collision 0.00 0.00 0.00 0.00
Trans Initially Deferred 0.00 0.00 0.00 0.00
Internal Buffer Error 0.00 0.00 0.00 0.00
Local Buffer Error 0.00 0.00 0.00 0.00
Buffer Unavailable 0.00 0.00 0.00 0.00
On Mon, Jan 14, 2013 at 07:29:01PM +0100, Erik Olofsen wrote:
With Google I found:
https://mail.encompasserve.org/anon/htnotes/note?f1=VMS&f2=2314.0
Erik
On Mon, Jan 14, 2013 at 05:54:54PM +0000, lee.gleason at comcast.net wrote:
I get:
$ patch monitor.exe
PATCH Version 5-05 20-June-1991
%PATCH-I-NOLCL, image does not contain local symbols
%PATCH-I-NOGBL, some or all global symbols not accessible
PATCH>exam 4158+33e
00004496: 00000000
Erik
The addresses of the structures changed for each version or so of VMS...you'd need to locate them with the fiche, or reading a dump of the image, or , for older versions of VMS, just using the Google to find one for your version. I enclosed that one just as an example of what gets patched.
Lessee....I also recall that MON ETHERNET required PHY_IO privilege, and needed a logical name NI$DEVICE set to be your network adapter's name to work.
--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.gleason at comcast.net
--
Dave McGuire, AK4HZ
New Kensington, PA
