On 26/10/2011 12:17, The Natural Philosopher wrote:
John Rumm wrote:
On 26/10/2011 10:47, Huge wrote:
On 2011-10-26, John wrote:
On 26/10/2011 02:05, Jules Richardson wrote:
On Wed, 26 Oct 2011 01:46:55 +0100, John Rumm wrote:
AFAICS there wasn't much in it.
I wrote in 8086 assembler for the 8086 board I designed. It
wasn't any
more difficult than assembler for the 68000.

You are having a laugh...

I actually assumed he was just trolling, because surely even he isn't
*that* crazy.

x86 was awful, it really was. Didn't its choice largely stem from IBM

Was? it still is (from a developers point of view).

The good news is that I haven't written any assembler since the
PDP11, and
when I looked at the '86 out of idle curiousity, it made me nauseous.

Well to be fair, its exceedingly rare that one needs to dabble with
assembler... Only had to do it once seriously on '386 stuff and that
was for built in test code on a 386 platform when there were no
compilers capable of generating protected mode code available for it
at the time!


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

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
8086. Slap in a bit of bank switch logic to page the roms about and they
would have been up and running almost immediately. Alas someone decided
to be clever, and use all the new toys to construct a logical mapping of
the required address space using physical to linear address remapping,
then create a virtual 8086 process to run in it, while rewriting a
premptive MASCOT kernel to keep tabs on it in protected mode. Took the
best part of two years to get back to a working system!

Used to routinely do comms stuff in 8086 assembler when writing the
main app in Turbo Pascal 3[1] - but that was because the language at
that version lacked the ability to do interrupt handling etc. Once
version 4 or 5 became available that was no longer needed.


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

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).

[1] Ah, the fond memories, an astoundingly fast and good compiler,
editor, and run time environment that all fitted in 50K on a floppy!

The number of times I have actually needed to code in assembler for
performance reasons, can probably be counted on two fingers in the
last twenty years! Once was the bitstream coding stuff on a system
with very tight and had real time limits. The other was for a Win 3.1
device driver that let you do synch serial comms with no extra
hardware on a bog standard PC!

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.

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!)




These days the horror of the '86 is hidden away several layers below.
Hell,

Indeed.

Agreed.


Still handy now and then to be able to drop a debugger into
disassembly mode and look at what is *really* going on though! ;-)


So rare as to be a complete tribute to modern compilers. I used to do it

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.

all the time to see what a mess they had made of the C code..Eraly C
cross compilers were frankly, ****e.

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.

[1] well allowing for not having done that much embedded stuff in the
last ten years - but I doubt the situation has changed too much.


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

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!


[1] But they did dominate the market since very few vendors were
interested in making CORAL compilers...



--
Cheers,

John.

/================================================== ===============\
| Internode Ltd - http://www.internode.co.uk |
|-----------------------------------------------------------------|
| John Rumm - john(at)internode(dot)co(dot)uk |
\================================================= ================/