OT: Good place to ask about XP memory problems

But were very limited in RAM.

Thats because grunts like me had written all te hardware BIOS code for you :-)

Probably the worst systems programming language I have ever been exposed to, pascal.

Writing a Pre-emptive multitasking kernel to slide under DOS2.2 was probably the last one I did..what a horrible thing to have to do. There was one bug I couldn't get rid of. Some things you might be doing on te PC would crash it

But since that happened fairly often with DOS2.2 it wasn't a practical issue.

Agreed.

So rare as to be a complete tribute to modern compilers. I used to do it all the time to see what a mess they had made of the C code..Eraly C cross compilers were frankly, s**te.

Mark Williams, Digital Research, BDS, Introl.. not one of them was anything like intelligent.

When the 8086 was common currency, I was writing Mesa and Interlisp for the Xerox 'D' machines(*). We fell about laughing when we saw our first PC (an Olivetti of some description, IIRC). I guess we're not laughing now.

(*

IIRC, the last assembler I wrote was MACRO-11 on a PDP11/70 under RSTS-E. It was a program to print questionnaires for the English Tourist Board (of all things), they needed it really quickly, we'd only just installed the '11 and MACRO-11 was the only programming language I knew that it had installed. I learned BASIC+2 after that as quickly as I could.

Before that I was doing process control, again on PDP-11s, for United Biscuits, where performance counted (in one project, we were weighing flying crisps), so we did the real-time stuff in MACRO-11 and everything else in RTL-2.

Naah. I no longer care. And the developers work for me anyway. As long as they know how to do it. All I want is a quiet life. I'm certain those times were nothing like as good as I remember.

Hardware BIOS, not on this box... (embedded military application).

This was all embedded (4MB of ROM in the days when that was *vast*).

This was a system that was built to originally run on 8086 systems, but they ran out of CPU oomph and ROM space. Someone had the bright idea switching to the then "new" 386, which in itself would have been fine if they had done what the PC makers at the time were doing - i.e. let it power up in real mode, and leave it there behaving like a really fast

Well there was Pascal and Turbo Pascal. Pascal was elegant, nice to read but relatively ineffectual in real world applications unless extended. When you think there were 25 odd built in functions in normal pascal, and 600 odd in turbo, it was not so much pascal with extensions as extensions with pascal. The result was a very good "kitchen sink" environment, in which you could do just about anything. Turbo C came later, but was never as nice (and way slower compiling).

I remember having a new grad working with me once, who had been set a job like this for some course work... I seem to recall getting roped in to debug it for him! (it was actually quite entertaining since he was studying at my old college, and had the same lecturer who about seven years previously had also take some of my classes. Hence there was some satisfaction to tracking down the bug to a flaw in the template code that the lecturer had furnished for them to build on!)

Last time I recall needing to do it was not really for a compiler problem as such (was using Borland C++ Builder for Win32), but a subtle coding error. There was a routine that seemed to suffer local variable corruption in the process of running. Turned out the problem occurred as you stepped over a function call - even though stepping into and out of it seemed to work ok, and the function did whatever it was supposed to as well. It became obvious looking at the code that it was mishandling the stack frame on entry and hence corrupting the stack frame of its caller - however by fluke, did manage to clean up the stack on exit and return to the right place. It transpired someone had coded a library routine with a different stated calling convention to that declared in the functions header file, and the compiler had not noticed. Hence the compiler built the parameters to be passed in to one standard, and the function processed them as if set out for a different one.

In many cases its not that much better now[1] alas. The main problem seems to be that a well known and used embedded development systems may get tens of thousands of users at best, whereas even an obscure native PC one will get millions. So there never seems to be the same pressure to find and fix the bugs in the same way.

Two that stick in my mind were Systems Designers (SDL, later SD Scicon) for their astoundingly bad CORAL compilers[1] (wrong code, non executable code, oops I forgot to load a segment register code etc), to "oh dear, I seem to have crashed, did not want a diagnostic message as to why did you?", and Cosmic's 68K compilers... which was rather fond of the executable code delivery (instructions not on long word boundaries etc), and the hex file with the bytes in the wrong order!

In message , "dennis@home" writes

VM was around in the early 60s,if not before.

Ferranti, MU [1]ICT, EE, ICL. [1] That's Manchester University, not the 6-1 lot.

Not so much... CP/M 3+ was out by then, and that allowed access to more RAM with bank switching - and that was no more of a hardship than '86 style segmentation in many respects. Many early PCs only had 64K or 128K (not forgetting the "huge" 640K limit! ;-))

Yes, I think so... the 'leading' CPU would be able to detect the page fault but not act on it (because the 68000 lacked the necessary low-level gubbins to do so) - but the trailing CPU would know that the leading CPU had encountered a fault condition and was able to jump to some (user) code to handle the anticipated fault before it saw it, too. Presumably that user code then also restarted the leading CPU, and all was well.

You were lucky - it's probably one of the best processors to be made in the last 30-odd years. :-)

Yeah, there certainly was one eventually, though - ISTR Torch using it for their Unix machines (and doubtless many other vendors did too), before the '020 and '851 came out.

cheers

Jules

How do you know the disk access is swapping, and not just some spyware rifling through your bank-password.doc files and suchlike?

There were better processors about, there was the 32032 (which never caught on, I don't even remember who made it. There were 16 and 8 bit versions of it too.

Then there were the Texas ones that didn't have registers but used main memory and and address pointers. They were quite interesting.

Then there was the military Intel CPUs that used the packet bus for memory interfaces.

It wasn't until the 386 arrived and Intel pumped millions into rewriting Unix svr4 that 4k pages became standard. Up until then everyone had to design their own page hardware and they varied from 1k to 32k (maybe more) dependent on the machine.

Its a shame the segmented MMU in the 286 didn't catch on, it would have made secure code much easier.

The 386 was designed to run Unix not DOS. the DOS stuff was thrown in as an afterthought.

Apart from the Fortran I did at school, I learnt to program on the 8086. I didn't find it a problem. It did take a few weeks to produce working code.

Yes, sorry - posted in a hurry :-)

I remembered there being "history" there too, though - turns out that it was the System/23 Datamaster (which came out just ahead of the 5150); that used an 8085, but the experiences there fed the choice of the 8088 for the 5150.

Indeed - they weren't very common otherwise, at least for desktop/server use. I do have a 68008 coprocessor for a BBC micro; that one runs OS-9 (which is actually a pretty impressive little OS - it's a shame it didn't see more widespread use).

I've got an STE-bus 68008 board somewhere too, but I've no idea what it actually came from (quite possibly an industrial system rather than any general-purpose machine)

Do IBM even make PCs (as opposed to servers) any more? I remember they had a 'home' line in the 90s, but they were expensive and not of particularly high quality. I don't think I've actually bought a complete system since the early 90s, and I got out of playing the component upgrade game years ago too.

cheers

Jules

I never had speed issues. Space issues, maybe.

So what, C is still cr@p. You can't even write portable code on it without knowing how the data is stored in RAM as it gets it wrong if you try and use that layout for something like say hardware interfacing. Sure it will do "hello world" on most machines but if you are writing device drivers and stuff don't assume its portable because it isn't.

Because it happens when the memory use gets to a certain point.

You couldn't get the 8088 at the time the PC was being designed and built. I know, we couldn't get it either and had to use the 8086 even though it used up valuable PCB space.

You couldn't actually get 68000s either, not if you actually wanted to build and deliver a product.

Quite a lot of design decisions were made by what you could actually get in those days. Sure if you wanted one piece you could pay a premium and get one, but if you wanted hundreds/thousands you were in a different territory.

Well IBM obviously managed it, since that is what they shipped with...

In fact I am note sure that IBM ever made an 8086 box... using the 8088 until the release of the PC-AT

Again, not a problem out there in the real world it seems. Even IBM did a version of the PC with a 68K in it for emulating the System 370 instruction set...

The Sun-1 was 68K based, also released in 82. Seem to recall there were quite a few of those made as well.

They were even finding their way into arcade machines by then either augmenting or displacing the normal diet of multiple Z80s or 6502s

OS-9 still gets use as an embedded real time OS...

IBM was one of the first to bail on making PCs, first outsourcing the building to Lenovo, and then finally offloading them entirely.

Certainly not the 386, perhaps arguable for the 286.

The 286 made an acceptable unix chip but had to be kludged[1] to do useful stuff in the PC architecture. The 386 was specifically targeted to solve those problems (and many parts of its architecture have little relevance in other systems). The first mainstream commercial use of them was in the Compaq Deskpro 386 systems.

I built successful projects with my first B&D router. However compared to the Trend T5 I replaced it with, it was crap, and I would not want to go back to using it, having used something so much better. Just because one can do something the hard way, is not justification for never progressing beyond that.

Hmmm, must be why the SQLite code is written in C - portable between not just desktops with different endian-ness but all sorts of small devices too. Like your phone, prolly, Menace.