What job are you offering?
What job are you offering?
Commercial programming has always been for people who are out of touch with the realities of computing.
Interesting that it was considered to be a Master's, because
14 years previously, it was a Bachelor's at Essex, with the PDP8 as the vehicle.+1
None to you as I believe you have an inflated sense of your own ability. Which is why we would all like to see your CV, to see if you are worth talking to.
Once again, it is not I who resorts to personal remarks.
It is an opinion based on your own statements. Prove otherwise, with that CV, and I will apologise.
Of course, if you can't or won't, you simply affirm my belief, and that of others, that you are nothing but an insignificant troll.
Essex still using PDP8s for that purpose in 1991? Seems a tad unlikely,
+1
As you issued the challenge, what of your own verified CV, and who will you get to verify it?
If you dislike my sincerely and honestly expressed opinions, then KF me, for my opinions are not targetted at the lower intelligence classes who resort to rudeness when they encounter an opinion which they either do not understand or with which they do not agree.
Apologies, misread it. I was referring to the 1986 reference and my experience in 1972
Once againl, you have leaped into the incorrect assumption that Martin's systems were simple. From the post he made, they were not.
/BAH
In our shop, using machine language helped debug the hardware we were supposed to make work. Sometimes, it helped field service find the hardware bug. The monitor (kernal) was the best hardware diagnostic.
/BAH
To my way of thinking, even if you never use it outside the classroom, it's helfpul to have it rattling around inside your head--you never quite forget that underneath the expert systems and high level abstractions and pretty interfaces, it's still just a machine doing basic arithmetic and simple comparisons at a horrendous rate of speed.
It also gives a feel for what's fast and what's slow. While optimizing compilers and the like can do a lot, there are limits to the degree of programmer dunderheadness they can fix.
An excellent reason for writing assembler, especially if you find a need to tunnel under the OS to debug new hardware.
Another good reason is to cram code into a really tiny system, though that one seems to be disappearing quite fast when you consider what you can get done with a PicAXE and compiled BASIC.
Q.E.D.
Compiled anything is pretty tight.
Really there is no need for assembler unless the language you are using doesn't have the right constructs to access the hardware explicitly.
So the lowest bit of library code like
char port(char *portno); // reads I/O port and returns its value
has to be coded in a couple of lines of assembler...
There's a bit more in terms of interrupts and the like, but really, once you have written your 256 bytes of assembler, and have a C or other compiler, there is no need to pick up that assembler ever again.
On some simple chips of course it does give predictable timings, but not with modern cached and pipelined code.
Not to mention out-of-order execution and multiple pipelines.
we've had meetings (for decades) that a problem with students in graduate computer security program is that they want to spend all their time finding & exploiting vulnerabilities ... garnering peer points ... there is little or no peer points for designing and implementing secure systems.
360/370 had svc, i/o, program, external/timer, machine-check interrupts ... loaded new psw (instruction address) from low store at same time as storing old psw (interrupted instruction address). interrupts stored information about the interrupt, in the case of i/o interrupt, it stored the interrupting device address (channel, controller, device) and the status (channel status word).
old ios3270 version of "green card" that I did q&d convert to html
low store layout for interrupting, old/new psw, csw, etc
channel status word (for i/o interrupt)
certain kinds of remote terminals had several termainals connected to single device address/port/line ... so there was additional work to find out which of several remote terminals ... sharing same line ... was responsible.
note that 360/370 interrupts didn't save/restore registers ... so there was standard interrupt handlers to store registers of the interrupted process and load registers for the interrupt handler.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required