Programme in C on your PiDP-8

[Ian Schofield]

Dear All,

 Now that you have built your PiDP8/I this bit of software lets you programme in (slightly limited) C!! The package includes an x86 cross compiler and a native compiler that runs under OS/8. Check out the instructions in the archive and I hope that I have adequately explained how to make it work.

Have fun, Ian.

[Al Williams]

That's awesome Ian. Can't wait to try it. As a Dr. Dobb's alumnus, I an please to see Small-C still lives ;-)

[Al Williams]

The native compiler seems to work. I tried to get it on my main system disk, but wound up giving up and booting to your image.

However, the hosted compiler cores if I run it with or without arguments. Haven't looked into why yet. Could it be the 64-bit host system?

Very cool!

On Saturday, July 8, 2017 at 11:17:38 AM UTC-5, Ian Schofield wrote:

[Ian Schofield]

Dear Al,

 The OS environment for the native compiler is hard coded and needs an OS/8 image with SYS: and DSK: as available partitions  ... as supplied. It shuld work if other system devices are used just by assigning DSK: and SYS: to the actual device names.

 The hosted compiler is also totally unsafe and expects a single .c filnemame as the argument. Good point about a 64bit environment. Given the this compiler is mostly original SmallC and make a lot of assumptions about sizeof(<type>) I suspect that it will not work.

 Having said that, I use a code identical version running under windows 10 and compiled under Studio 2008. It is explicitly set to 32bit x86 for the studio(M$) compiler and seems to be fine. But, some C constructs in the C programme being compiled will cause exceptions.

Overall, this software is seriously beta but I hope it is of some interest.

Regards, Ian. 

[Al Williams]

I thought I had it set up right but will try again next time I get time. As for the other compiler, yeah I'm not surprised. Just thought you'd like to know someone tried it out. It did work fine with the supplied images native. 

[clasystems]

Just so all of you know, SYS: is the bootup device.  That can be changed in the grossest sense, but not adjusted.

For example, OS/8 for the RK8E supports a slightly longer bootup sequence allowing a choice of drive 0 1 2 or 3.  SYS is always the one that applies.  It is not setable in any other more nuanced sense.

DSK: is a placeholder for any device.  It often defaults to whatever SYS: is,but that is not a rule.  OS/8 BUILD is used to build a system that is a descendant of the one the BUILD program is run from, where any and all of the handlers are up for grabs, while the "generic" blocks are taken from the currently booted system.  Within BUILD is a command to default DSK: to any device in the target system being built desired.  Not using the DSK= xxxx command defaults DSK to SYS.  But in any case at any time AS somedev DSK always has the final world on this.

cjl

[Ian Schofield]

Dear Charles,

 Thanks for the reminder. I built the OS/8 system I am using so long ago... As you say, a quick check via BUILD shows the settings and allows a rebuild so that friendly device names will be set at boot. In my case I assigned: DSK=RK8E:RKB0 and SYS is the boot device (usually RKA0).

Dear Al,

 Just another one for the hosted compiler, I should have mentioned I am running it under Raspbian Jessie (4.1.19) on the Pi in my PiDP8/I. This is as 32 bit OS at the moment. In this env, cc8 seems to behave as expected when called with no args. Which Linux are you using?

Regards, Ian.

On Saturday, July 8, 2017 at 5:17:38 PM UTC+1, Ian Schofield wrote:

[CLASystems]

On Thu, Jul 13, 2017 at 1:48 PM, Ian Schofield <isy...@gmail.com> wrote:

Dear Charles,

 Thanks for the reminder. I built the OS/8 system I am using so long ago... As you say, a quick check via BUILD shows the settings and allows a rebuild so that friendly device names will be set at boot. In my case I assigned: DSK=RK8E:RKB0 and SYS is the boot device (usually RKA0).

​There is an anomaly [some would say a "feature" of that configuration [which I avoid because of the confusion as I reboot].  The standard OS/8 RK system does NOT have to be on RK0.  With a slightly longer [but still standard] bootup, it can be on rK1 or rk2 or rk3.  [And the SIMH config.ini file allows this as a standard feature.]

So, the RK system handler is thus equivalent to RKA <the drive you booted to> not just plain RKA0: [if you reconfigure what .RK05 image file is attached to what physical pack and then in turn what you boot to].

The RKB0: you chose is NOT RKB0: by the same token thus it is RKB <the drive you booted to> but it RETAINS the NAME of "RKB0" by the design of coresident handlers [and thus "lies" when booted to RK1 or RK2 or RK3.  But this still makes what BUILD set work!

I am at times developing P?S/8 for RK [I currently configure it for all the DECtape drives on the TC08 and OS/8 on all the RK drives.]   Thus, I will need to have OS/8 booted to one of the other three drives so P?S/8 can be built onto RK0.  [It is a rational restriction that building a system must be to drive 0.]

As such, I use the "real" handlers for all 8 of the drives from the non-system handler group.  That way RKA0: really is RKA0:, etc.​

 

​cjl​

Dear Al,

 Just another one for the hosted compiler, I should have mentioned I am running it under Raspbian Jessie (4.1.19) on the Pi in my PiDP8/I. This is as 32 bit OS at the moment. In this env, cc8 seems to behave as expected when called with no args. Which Linux are you using?

Regards, Ian.

On Saturday, July 8, 2017 at 5:17:38 PM UTC+1, Ian Schofield wrote:

Dear All,

 Now that you have built your PiDP8/I this bit of software lets you programme in (slightly limited) C!! The package includes an x86 cross compiler and a native compiler that runs under OS/8. Check out the instructions in the archive and I hope that I have adequately explained how to make it work.

Have fun, Ian.

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ycs_KOI4vdg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/2635fc5e-6b9b-4e06-abcb-cc4736080ccb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

"In the future, OS/2 will be on everyone's desktop"

Bill Gates, 1992

[alank2]

This is beyond awesome.  I have wanted a C compiler for the PiDP-8 ever since I got my hands on it.  I'm sure I'll have questions once I start testing/playing with it!

[clasystems]

There are many ways to implement code from a compiler for the PDP-8.  The Fortran IV does NOT, instead it outputs FPP code, and the BASIC runtimes in OS/8 are somewhat similar.  The only successful one is the SABR output of the Fortran II compiler, and a user-written near Fortran IV called FORTX exists using the same run-time.  It uses some what some people call "threaded" code.  The point is it implements better on the PDP-8, and won't take tons of memory to do very little.

cjl

[Murray Williams]

One thing I had really wanted to do on the PDP/8 that I later found out I couldn't but now I can, thank you!

[clasystems]

On Saturday, July 15, 2017 at 2:19:35 PM UTC-4, Murray Williams wrote:

One thing I had really wanted to do on the PDP/8 that I later found out I couldn't but now I can, thank you!

Projects like that have to be refined.  There is also a PASCAL for the PDP-8 that was "ported" by essentially creationg a p-machine executor of primitives and a run-time of PDP-8 code to make that work, etc.  When enough of it was working on the PDP-8, it was capable of compiling itself.

The most important thing on any of these projects to be practical enough is to decide exactly what code you want to produce and how to execute it.  Fortran IV was constrained because it was required to support the FPP-12 [and later the FPP-8/A, but actually the subset the same as the FPP-12; the frills, although nice, didn't matter in the run-time system.  As with many PDP-8 features, all you got was the ability to detect which exact hardware you had, that is if you cared, but in the main, no real improvement.]

One constraint is inevitably that doing it this way you get 15-bit addressing so that with a decent amount of memory [SIMH always provides the full 32K] you can have decent size binary actually running so it's not in any sense a toy, etc.  Then an FPP simulator was added so that the programs could run on more machines, etc.

The BASIC run-time worked out an alternate model because in some ways, the FPP-12 is not that great for execution in general.  [Give it a B-]  Whether or not the BRTS is an actual improvement is debatable, but they

 rejected the FPP as defined.

Note:  There are 24-bit data formats [and double-precision that really adds 12-bits more to each variable; FOCAL has this as an add-on for example] and there is a 27-bit package that somewhat limits the range of exponents so they the truly infinitessimal and truly humongous are not allowed and instead favor more precision.

Then there is the nuts and bolts of the emulated instruction set.  The original software FPP mimics the PDP-8 instruction set which may be easier to deal with at the assembler level, but another package used in 4K BASIC and 8K BASIC uses relative addressing as used in other machines, and sometimes this implements either smaller overlal, or perhaps faster overall result.

My point is these are just some of the decisions to make even before you start on what compilers compile.  All of them avoid the PDP-8 field-addressing housekeeping because these are 15-bit addressing execution modes.

As some of you know, I am developing P?S/8 which has a far superior memory model.  My friends at DEC admitted it's better, but were too lazy to change anything!  Instead, every one of those run-time programs use ugly kludges just to badly do what naturally happens in P?S/8 by design.

From the vantage point of someone wanting to implement any such project, they can appreciate the better memory model because it makes their job easier and an ability to produce larger programs.  Without going into great dettail, here is what you need to know:

1)  P?S/8 is a 4K system minimum.,  There are reasons to back-pedal that for a variety or reasons [incluing modular optional features OS/8 doesn't even support at the conceptual level].  There is no valid reason for OS/8 to have a demand for ANY page of memory beyond all of field 0.  [Field 0 is not available due to HARDWARE-derived reasons.  3-cycle DMA devices such as the TC01/08 DECtape, the TC59 magtape, and the DF32/RF08 require the hardwired addresses 07757-07755.  This was actually planned around the minimalist design of the RIM loader, the shortest STRAIGHT-FORWARD loader that can be placed at the end of memory.  Location 07777 is not actually part of the loader, but is reserved as where a JMP instruction is to the particular BIN loader is loaded in slightly lower memory; this is important as there are at least four different specific BIN loader implementations and there cannot be consensus on the exact starting point, but by having a JMP in 07777 to the current internal start, the documentation always applies; just start the BIN loader at 07777, etc.

Generalizing out from there, it is not much of a reach to make the last entire page of memory off-limits to programs [since it is not much more than a nitpick once you have BIN then the reserved locations then RIM then the JMP to BIN start at 07777.  The P?S/8 version can make all that fit in 07642-07777 leaving 7600-7641 to nitpick over.  That is the definition of the largest amount of code that is constrained to start at 07600 that can in general reboot P?S/8 when paper-tape operations are not currently needed, since it is a mass-storage system, not a pape-tape system,[but it can interoperate with the paper-tape system when you need it/]  Thus, you can have 00000-07577 as a user program and the system "owns" 07600-07777.  All PDP-8 operating systems that "matter" in any sense are designed to conform to this.

But OS/8 then also takes out 17600-17777.  But I have proven for years this is simply not justified and based on a copout and shortsighted kludge just to expediently get up a poor design, which was then fixated and not going to be revised.

But P?S/8 was from the 4K era where such silly decisions were not made so expediently.

So, P?S/8 worked the other end.  Within the kernel code in 07600-onward are control bits that any conforming program can access.  This determines the HIGHEST field of memory that is FREE TO USE for all user purposes.

There are several optional components in P?S/8.  Assuming 32K, ALL of them go into field 7.  User programs can 100% use with impunity 10000-67777.  This is a far better outcome than OS/8 because there is no "wasted" field 1 section.

So, how was this accomplished?  [Shorter answer, by applying THOUGHT PROCESS!].

OS/8 [tries to] support devices where the system handler cannot work in only 07600-07777.  [That happens.]  Since they foolishly wasted field 17600-17777, they then had to use 27600-27777.  This is idiotic and worse, it doesn't really work.

P?S/8 is based on the notion that there should not be any device it cannot handle WELL as oppposed to the usual miserable way OS/8 does.  Everything in OS/8 is capable of being jettisoned in terms of performance, error recovery or other compromises.  It's pretty much true ALL the handlers are compromised for the want of a nail or three.

Thus, the P?S/8 memory model is either a)  You get it all to fit in 07600-07777 or you don't.  If not, you can have x6000-x7777 whee x is the HIGHEST memory field available.

Thus, so far, if you cannot run in 4K, you do need at least 8K, but if you have more, the more you have, the higher and more out of the way the rest of the code is.

Before you look at what OS/8 tried to do, let me show you the deal-breaker:

On the DECmates II and up you have to support the RX50 diskettes.  Besides due to other poor design aspects that OS/8 variant "OS/278 V2" is so incompatible and non-functional, the fatal blow is this:  Perfectly reasonable commands that work in OS/8 are available in this variant system.  And it works fine if your system device is the RD5x hard disk. But, if your boot device is the RX50 [and most DECmates ONLY have the RX50!] then executing these commands PERMANENTLY CORRUPT THE DISKETTE!

I've disassembled the ROMS of the DECmates [some copies of part of what I have done are on-line if anyone cares], so I know WHY this is true, but there is nothing that can be done about it.  Thus, because OS/8 is so painted into a corner, it is IMPOSSIBLE to overcome this serious problem!  [So, it's documented, thus it's the old "it's not a bug, it's a feature!].

But to solve this in P?S/8 will take most if not all of the additional 1K of code that becomes available.  Thus, given this problem, it is not necessary to discuss the lesser problems, but for example, the P?S/8 RX01 system handler needs THREE pages of code to ELEGANTLY handle what OS/8 VERY BADLY handles.

Now back to what a compiler designer wants to hear:

If the configuration is only as described above, you can have 15-bit addressible contiguous address space from 10000-75777.  Thus, this is already more than OS/8 can offer any of this class of program.

OS/8 miserably attempts to glom onto 17600-17777.  In the extended P?S/8 "SHELL" definition, there is a need to have a 256 word area of program communication.  [Note: The P?S/8 SHELL definition includes 12-character names with four-char extensions.  That's literally DOUBLE what OS/8 supports, and additionally is case-retentive but not case sensitive [See OS/2 for an example of this].  Thus, each relevant filename specification needs twice as many words to store there, and it adds up quickly, etc.]

So where does this area "live" The answer is found in more kernel bits.

1)  If the SHELL is not enabled, it is nowhere to be found.

2) If the SHELL is enabled, it depends on another bit.

3) The other bit if set means it is in x5400-x5777 where the same memory field x applies.  Thus, two more pages are carved out that are reserved.  But if you read the kernel bits, you still get 10000-75377 assuming 32K even with this situation.

4)  If the bit is clear, the two pages are NOT memory resident.  Instead, the contents of two adjacent 128-word  blocks are used.  The blocks are defined as very low blocks in an even odd pair, so it typically implements well.  So, why is this not high-overhead?  Because generally, these parameters are by design only needed for the benefit of the file-handling portion of the operating system in the SHELL and nowhere else.  Thus, when these components are loaded, the device is already "close" to where these two blocks are anyway.  If you look at this on actual DECtape, you see that the overhead is really not that much.  [Of course, in OS/8 this overhead happens anyway, but you are still wasting field 1 7600-7777.  Had it been an option do to it "my way" you would see that the overhead beyond the necessary overhead is surprisingly small.  Thus, why compromise things otherwise?  The rest of the differences in the SHELL as compared to OS/8, stated in a slightly oversimplfied way is that essentially, all the limitations don't exist for a variety of reasons.  OS/8 has the dubious distinction of being just about the only operating system where the underlying storage cannot be accessed because the directory got prematurely full just because you have a totally reasonable number of files.

The above is also a consideration for most compiler designers:  You probably want the user to have hundreds of individual files for a variety of purposes.  Unfortunately, OS/8 will run out of gas unless you are VERY careful.  this simply will not happen in the P?S/8 SHELL because of the superior design.  This is the theoretical maxxed-out comparison:  The P?S/8 SHELL can in theory address 2048 times as much storage as OS/8!  Go back and read the last sentence, it's not a typo.  OS/8 kludges 12-bit work of double-pages to cheat into 13-bits of storage addressing with some serious compromises.  P?S/8 non-system handlers use 24-bits to address single-pages so you get both smaller minimum buffer sizes, but 2048 tims as much storage being addresses!  Since P?S/8 device handlers support logical units [another thing OS/8 never did, yet it was planned!\ and assuming  6-bits is a byte [which is often the case on real storage devices] that means the scope of a SINGLE P?S/8 non-system handler is up to 32 GByte!

As a practical matter, OS/8 needs up to 8 handlers to address up to 8 DECtape drives.  It also needs up to 8 handlers to address 8 1/2 drives of the RK8E/Rk05.  P?S/8 needs only two handlers, one for all 8 DECtapes and another for all four RK drives.  In fact, there is the obscure RKS8E controller that can address 4 more drives.  OS/8 ran out of code space to support those drives, so there is a separate handler for those other four drives.  There is is simply no way to trust this handler; if you don't actually have the RKS8E, it will corrupt your disk contents as it lets you with impunity!  But this is unnecessary, as with larger handlers, you can check the hardware and if this is an ordinary RK8E, disallow access to the other four drives and return an error.]  In SIMH as it stands now, that means the P?S/8 non-system RK handler addresses RK0, RK1, RK2 and RK3 each with blocks 00000-31277.  OS/8 has to address up to 8 handler-limited half-drives.

And remember, OS/8 only defines a maximum of FIFTEEN handlers [and one of them is DSK, a placeholder for one of the others].  Thus, OS/8 CANNOT address all of those DECtapes AND RK half-drives at the same time!  You have to use OS/8 BUILD all the time and kludge your way through using a subset of what you have.  [On my real PDP-8/E-A system, I had several devices and had about 10 different saved copies of BUILD, each slightly different just to be able to "navigate" the hardware I actually had!]

Thus, overall, the little 4K system "leap-frogged" over the "big" 8K system into something that is geared to MORE memory, up to and including 32K handled well and not kludged.  This is something compiler designers need to hear, etc.

[For those who don't know this part, P?S/8 was offered to DEC, being cheered on by my friends there who lobbied for it. The idiot managers rejected it out of a power-play attitude over them as spite-work, not what was good for the company.  As a result I sold a limited version of the system to Intersil corporation for their then-new Intercept 1 based on the IM6100 run at proper speed.  That machine can be liked to a beefed-up VT78 where everything runs slower,but is otherwise comparable.  Since this was s strictly limited license, I retain full control over P?S/8 and it will shortly be released [sans the SHELL] as part of my PEPS package for Windows using the original 12-bit SIMH.  Any serious user of the PiDP-8 should also be running this package because they complement each other.  for more information, please join the pepswin group.]

At some point with certain modifications at the 12-bit level, PiDP-8 can also run P?S/8,  It us also running on certain real PDP-8/I systems.

cjl

[Ian Schofield]

Dear Charles,

 Thanks for the further info as above. The intention here was merely to create a very simple and minimal implementation of a subset of c so that the users can have a play in a familiar language. This is implicitly 12 bit and as a result there is up to 4k of code addressing 4k of data. To extend this is a significant task and would result in a lot of obscure code at runtime for an inline model or a rather complex p-code model as per Basic/Pascal etc. Limiting the whole thing to 4k and using an inline model is, I hope, a bit more informative in regard of writing code for this processor. I look forwards to seeing P?S/8 at some stage and I hope that it allows for an easy extension of the programme and data spaces such that this compiler can be extended.

Regards, Ian.

On Saturday, July 8, 2017 at 5:17:38 PM UTC+1, Ian Schofield wrote:

[CLASystems]

On Sat, Jul 22, 2017 at 1:59 PM, Ian Schofield <isy...@gmail.com> wrote:

Dear Charles,

 Thanks for the further info as above. The intention here was merely to create a very simple and minimal implementation of a subset of c so that the users can have a play in a familiar language. This is implicitly 12 bit and as a result there is up to 4k of code addressing 4k of data. To extend this is a significant task and would result in a lot of obscure code at runtime for an inline model or a rather complex p-code model as per Basic/Pascal etc. Limiting the whole thing to 4k and using an inline model is, I hope, a bit more informative in regard of writing code for this processor. I look forwards to seeing P?S/8 at some stage and I hope that it allows for an easy extension of the programme and data spaces such that this compiler can be extended.

Regards, Ian.

​OK.  P?S/8 uses a more rational memory model, which I offered to my friends at DEC [who wrote OS/8].  They are a bit lazy, but to be fair, management were all dolts and couldn't care a rat's ass, and thus TWICE they rejected P?S/8 even though it was perfect for some of their express needs on 8/A sales, etc.  Thus, between they not being motivated, and management fools just wanting short-term solutions [like their paycheck] it was never implemented, even though for the various language run-times they had to badly kludge what would have been "natural" using the P/S/8 scheme.

Every P?S/8 system offers 00000-07577.  This is true in a 4K machine.  If 8K is available AND the handler is not of the "extended-memory" variety then the entirety of 10000-17777 would be available.  And this applies for literally the rest of extended memory up to say 32K on such a system.

Some devices cannot be implemented in a system device handler in 07600-07777.  It's fairly analogous to OS/8 needing 12K.  [Note:  I can prove that the design of OS/8 has no business reserving 17600-17777; it just hatched that way, but no on is gonna ever fix OS/8.  And no need to, as since P?S/8 is still being developed, one of the eventual goals is to add a "SHELL" that allows all of the OS/8 programs to be "migrated" to that environment.  [Not binary-compatible, but  by nature, most programs have pretty much the same small set of code that talks to the O/S.  That would be done differently, and thus there should mostly be a "cookie cutter" approach to that, etc.]

Should one of these problematic devices  be the system device, the entirety of an entire 1K of code is reserved in x6000-x7777 where x is the highest field of memory.  Thus, you can have a continueous space of 10000-75777 on a 32K even if this is the case.  This suggests the use of a 15-bit addressing mode such as is used in the various OS/8 BASIC implementations and the Fortran IV runtime systems [all of these need to have the kludges REMOVED].  This is still better than OS/8 because field 0 is never reserved at all [except of course if the machine is 8K specifically and a device that needs the extended-memory extension].

The initial PD release of P?S/8 connected with the PEPS for Windows project is for TC01/TC08 DECtape with logical units 0 through 7, and that is a no-hassle system that runs in 4K, thus the handler extension requirement does not exist for that system configuration.

All of that said, P?S/8 also supports a unique feature known as the Logical Console Overlay.  The typical short routines to use device 03/04 [and the device 66 LPT] are changed to JMS calls to specific locations on page zero of the field x, the highest field as defined above.  Conforming programs can self-configure because the info about what field and if the Logical Console Overlay is in effect is determined from the resident system kernel in 07600-07777.  There is no actual "handler" for the printer, it MUST be device 66 [which is the default in most situations including SIMH].  However, the Logical Console Overlay allows such configurational changes as using a serial printer that requires Control-S/Control-Q protocol [such as device 40/41 or 65/66] so conforming programs can output to anything, even in theory to the contents of a SPOOL file, etc.

Since the Logical Console Overlay occupies essentially 0000-5777 of the same field [the highest one] then if it is present, no access can be made to the highest field.  But for a 32K machine, this still means a contiguous address space of 10000-16777; OS/8 cannot do this

The Overlay is being slightly modified to lower the occupied memory to 0000-5377.  No existing configuration ever really needed the memory, just that as assembled it became an excessively long part of the buffered LPT support.  [You really do not need more than two full lines buffered plus a few exta[ so this is not a problem whatsoever.

This is where OS/8's dud of a design comes in:

The reason for OS/8 "needing: the field 1 7600-7777 part is a combination of poor code, bad bootup design and a "crutch" in that there are some words there for inter-communication between portions of the USR talking to each other.  In the P?S/8 SHELL design, that is enlarged to 256 words, in part because the system features will be more comprehensive and partially because the file structure is far better.  MS-DOS is referred to as a. 8.3 system.  In those terms, OS/8 is 6.2.  The P?S/8 SHELL will be 12.4 with case retention somewhat like OS/2.  For this and an assortment of other reasons, the area is being made very generous to prevent being "painted into corners" which is a pervasive problem of OS/8.  I think 128 words, the next natureal size down might be marginal, but 256 sounds like it always pass muster no batter what, etc.

A bit in the resident kernel determines where this 256 word area is.  Either it is going to be in x5400-x5777, thus in between the Logical Console Overlay and the device handle extension [still allowing 0000-5377 of contguous memory]  OR it will be virtualized to the contents of two adjacent blocks in physical proximity of the system services.  [Note:  User Service Routine is a boring name, so I am calling it the User File Operator or UFO.]  Thus, even if on a tape-based system such as DECtapes or LINCtapes, there will be little additional overhead, and​

 

​relatively moot for more powerful devices.  User configuration allows choice and performance can be measured, etc.

Since this is also in the highest field of memory [if it even is in memory!] this means that what OS/8 was trying to do in field 1 is just a collection of poor choices and was thus never justified.  [P?S/8 has more in-kernel info than OS/8 does located in 07600-0-7777].​.  All of this should be inviting to anyone attempting to write a viable run-time system for any language, etc.

cjl [for more info, join the pepswin group, where this will be announced]

On Saturday, July 8, 2017 at 5:17:38 PM UTC+1, Ian Schofield wrote:

Dear All,

 Now that you have built your PiDP8/I this bit of software lets you programme in (slightly limited) C!! The package includes an x86 cross compiler and a native compiler that runs under OS/8. Check out the instructions in the archive and I hope that I have adequately explained how to make it work.

Have fun, Ian.

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ycs_KOI4vdg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/24dbb8f3-4fd4-4e41-a2aa-9683f4410c48%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jonathan Trites]

I just wanted to say thanks to Ian for the C compiler and Warren for integrating it into his latest distribution version. I haven't done anything more than compile the included fib.cc, calc.cc, and ps.cc demo programs, but to know there is a C compiler, a language I actually know and use, even if somewhat limited for understandable reasons, is really cool.

So, thanks guys.

On Saturday, July 8, 2017 at 11:17:38 AM UTC-5, Ian Schofield wrote:

[Warren Young]

On Sunday, July 30, 2017 at 11:07:14 AM UTC-6, Jonathan Trites wrote:

I just wanted to say thanks to Ian for the C compiler and Warren for integrating it into his latest distribution version.

You're working with the cc8-merge branch? It should be stable enough to play with, but expect the release version to differ. Bill Cattey is working on an entirely new OS/8 RK05 disk pack, which will differ in significant ways from both Oscar/Rick's os8.rk05 image and from Ian Schofield's cc8.rk05 image.

Essentially, it will be a merger of both, plus some changes.

I'm not going to list them, since ultimately, it's up to Bill what it ends up looking like. I've made some suggestions about what I'd like it to look like, but I wouldn't have given him the project if I wanted to control every aspect of it. :) 

[Jonathan Trites]

Yeah, I was just playing with it. I wasn't dedicated enough at the moment to try and get Ian's zip file working, but I keep tabs every now and then on your timeline page in order to do a pull and saw it had been integrated into the cc8 branch.

[Jonathan Trites]

I will admit I should have used better wording. It is the latest stuff mentioned on the timeline, not latest on the trunk branch or release tags, so I guess not really "latest distribution version" like I had said. More like latest checkins.

[William Cattey]

In the cc8.rk05 image in Warren's cc8 branch, there's a file:  CCBTCH.TM

It looks like an OS/8 batch job that calls itself infinitely, and pours what comes in from the TTY into CC.CC.

Is this the PDP-8 side of a tool to paste C programs in via the terminal?

-Bill

[clasystems]

On Wednesday, August 9, 2017 at 10:59:20 PM UTC-4, William Cattey wrote:

In the cc8.rk05 image in Warren's cc8 branch, there's a file:  CCBTCH.TM

It looks like an OS/8 batch job that calls itself infinitely, and pours what comes in from the TTY into CC.CC.

Is this the PDP-8 side of a tool to paste C programs in via the terminal?

No, it is an artifact of running OS/8 BATCH for whatever purpose.

cjl 

[Bill Cattey]

Oh right!  ".TM" is the conventional extension for temporary files.

-Bill

clasystems

August 11, 2017 at 12:15 AM

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ycs_KOI4vdg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.

To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/56a14bfc-a509-4bae-bb65-4be78b08ef02%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

William Cattey

August 9, 2017 at 10:59 PM

In the cc8.rk05 image in Warren's cc8 branch, there's a file:  CCBTCH.TM

It looks like an OS/8 batch job that calls itself infinitely, and pours what comes in from the TTY into CC.CC.

Is this the PDP-8 side of a tool to paste C programs in via the terminal?

-Bill

On Saturday, July 8, 2017 at 12:17:38 PM UTC-4, Ian Schofield wrote:

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/ycs_KOI4vdg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.

To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/b7f44dd4-944d-4e21-80f1-ec8606edbf74%40googlegroups.com.