They don't come much more Vintage than this
 

Re: They don't come much more Vintage than this
 

I once had an interesting chat with someone who programmed computers in the early days. There were no high-level languages, not even assembler. They had to program directly in machine code. Debugging must have been almost impossible.

Re: They don't come much more Vintage than this
 

The big problem with programming directly in machine code is that if code needs to be moved, any address references need to reflect this.

When writing machine code patches for existing object code, there was the additional problem of trying to fit the new code over the code it was replacing. Fortunately, I only ever had to make very minor alterations by this method.

Re: They don't come much more Vintage than this
 

Ah but...the thought process and discipline using machine code ensured a very efficient program usually needing only a few hundred bytes rather than the megabytes even the simplest of functions seem to need today. The worst part was preparing paper tape with a uni-punch....!

Re: They don't come much more Vintage than this
 

Brilliant! I have a book 'Electronic Brains' by Mike Hally which deals with the early machines which were built for the military (usually ballistic calculators etc) and the early university machines. It's fascinating, as is another book which charts the development of LEO, the Lyons machine. I could read this stuff all day.

Re: They don't come much more Vintage than this
 

We used machine code exclusively when programming early Z-80 based coin-in-the-slot video games. There was no assembler that used code efficiently enough to make the games fast enough on a 1MHz processor. It was a choice to gain every last bit of speed - we even selected the op codes in a routine to use the minimum number of clock cycles.

And then there was the problem of squeezing it all into 16k of EPROM, we sometimes used 32k but that was frowned upon, memory was very expensive.

Re: They don't come much more Vintage than this
 

I'm a little puzzled by this, as my experience of writing in assembler, albeit on rather different machines, was that the assembler was creating exactly the same code as coding directly in machine code - but simplifying things by using instruction names and symbolic addresses rather than their numerical equivalents. My assembler routines were therefore every bit (no pun unintended) as efficient to run as code poked in directly in hexadecimal, but without needing to know exact addresses or offsets for referencing data or jump destinations. I have always seen this as the distinction between assembler and high-level compiled languages - don't even mention interpreted code (nasty inefficient stuff for running on machines with lots of redundant capacity).

Re: They don't come much more Vintage than this
 

My very first programme was written in Cecil https://en.wikipedia.org/wiki/CESIL running over a teletype link via a (very slow) modem to an IBM 360 in Cambridge. Such joy when it worked!

Re: They don't come much more Vintage than this
 

I know it's new fangled compared, but I started programming by going on a course after having been an operator for a while. We started with COBOL, but I enjoyed IBM assembler and even better - ICL PLAN. Multiplying two long numbers required "double length aritmatic" (or even adding if I remember correctly). Like most people over a certain age, I don't like VB and Java etc.
Stuart.

Re: They don't come much more Vintage than this
 

Yes, but your fancy assembler probably was using separate numeric constants .....

Suppose you need the constant 3 in your program. On the Z-80, the byte 03h corresponds to the opcode for LD [BC], A. If you happen already to have the instruction LD [BC], A in your program somewhere, then you can use the address of that instruction as the address of the operand, and it will fetch that three, rather than deliberately populating a separate memory location with 03h and then pointing to that address.

Admittedly, since the Z-80 includes an immediate addressing mode (where the next byte is the operand itself, as opposed to using the next two bytes to indicate the address where the operand is to be found) this particular technique is less useful. An instruction to read a byte from a fixed location, such as LD A, [$4C2B] requires three bytes (and also the desired value in the pointed-to location, here $4C2B; making a total of four bytes if that value has to be populated specially) whereas an immediate-mode load such as LD A, $03 requires only two bytes and fewer clock cycles, since it already has the wanted value without the need to do another memory access. But this technique was certainly used on some early architectures without an immediate addressing mode.

If you need to set the accumulator to all zeros, the obvious LD A, $00 is two bytes; but EOR A, A is one byte (and fewer cycles). And then there are situations where a little inside knowledge of the machine state lets you get away with something -- for instance, storing a temporary value somewhere that will get stomped on later but not until you have already used it; such as just below the stack pointer, where it will be overwritten by the next PUSH or subroutine CALL instruction, or over a system variable which will not get updated until some other event has happened, such as a keystroke or the start of a new video scanline.

An assembler would also reserve separate space for all variables; when in practice, you might have finished using one before you stored anything in another.

Yet one more common optimisation you can do by hand on the Z-80 and the 6502 is to use a two-byte relative jump (which happens only to be available as a conditional instruction), if you know in advance that the processor state will always be favourable (e.g., a SUBtract or DECrease instruction will always leave the carry flag set if it produced a positive value), as opposed to a three-byte unconditional absolute jump.

It might seem crazy today, when you can run interpretated languages on a Raspberry Pi; but there was a time when all this made sense, because every byte and every clock cycle mattered.

Re: They don't come much more Vintage than this
 

I'm with Dave Moll, slightly mystified in the sense that as far as I know you can perform any explicit machine code manouvre you need to in assembly language, since each single line of pure assembly language generates one absolute machine code instruction.

For example

The allocation of memory space to variables is entirely under the control of the programmer in assembly language. Conventionally, loop counters and so on tend to be given meaningful names and so individual addresses are reserved for them, true, but it would be simple to give a variable a name like GeneralPurpose1 and re-use it 'locally' in several different places. The onus then falls on the programmer to make sure that no two independent program entities (such as a main loop and an interrupt routine) try to use it at the same time, but it is perfectly possible to exercise that level of control in assembly language.

Those of us who had very early 'computer' systems (ie, MK14) had little choice other than to enter code in machine language, but when we did, we ourselves were only doing what software assemblers later did for us: translating human-readable assembly language mnemonics into the corresponding machine code.

There is an undeniable degree of pleasure to be had from being able to write in actual machine code (I'm very fond of Z80 in particular and can remember quite a few of the opcodes even now) but I wouldn't want to go back to the bad old days of having to shuffle code around by hand and recalculate all the jump offsets / addresses affected whenever a few bytes have had to be inserted into some code.

Re: They don't come much more Vintage than this
 

No need to do this on the Z80 as it has a 2 byte unconditional relative jump instruction i.e.

JR xx

with the opcode 18H in the first byte and 2s complement offset in the second.

I too am mystified about the statement that programming in assembly language is somehow less efficient than programming in machine code. If they felt so inclined, the assembly language programmer could employ any of the tricks stated above.

John

Re: They don't come much more Vintage than this
 

It was 40 years ago now and my memory isn't what it was, but we would use machine code rather than assembler on the Z-80 because we could always use less memory and because we could select op codes that used fewer clock cycles, both of which were important considerations. Possibly the assembler available to us at the time didn't allow us to do one or both of these things. I don't remember any irritation about programming in machine code, my feeling now is that we had some satisfaction in making code as efficient as possible :-)

I still have my Rodney Zaks book on the shelf!

Re: They don't come much more Vintage than this
 

I must admit that I began by learning machine code (on 6500 series, Z80 and 6800 series) and except for hand assembly did not really use an assembler. As such when I first looked at progressing to what should have been an easier way I did not get on with it. I could remember the op codes without problem after a while so preferred to use machine code as I visualised the operation of registers etc which is something that tends to get more remote the higher the level of programming language. It made things easier when I came to build my, designed by me, development system for my college course project (6802 based).

With the fixed position in memory of code, as others have said, relative addressing will sort. It depends somewhat on the capability of the monitor(basic system) program. I think this is one of the reasons 'com' files got replaced by 'exe' as this enables the file header to be in a different place to the program itself, just containing a reference jump to the program.

I have not been too involved too much of late, although I notice from the manual of the Arduino controller chips that things have got somewhat more complex than the 6502 etc. That said, unless there is reference to a changed hardware function, things can be built up from basic instructions. With my system I spent many a hour contemplating virtual processors with my own machine language and even programmed the system up to work parallel processing although it was a little unstable (maybe all the pushing and pulling off the stack at each change of thread was the issue as it is easy to forget something - even these days when I do it in far higher level language)

Re: They don't come much more Vintage than this
 

I too am puzzled by the claim that assembler is somehow less efficient than machine code. This could only be true if the assembler sometimes tried to do something other than what is given in the source code e.g. an attempted optimisation which turns out to be unhelpful. Most assemblers don't do this, and any competent assembler which did should be able to have this facility switched off.

The big advantage of writing in assembler is that you can write maintainable code. Very little code survives for long without needing modification, for debugging or enhancement. Assembler can contain comments and symbolic names. If you want to save data space by re-using it, you can do this by just giving several names to one location - but then be careful that the different uses do not overlap under any circumstances! If you really want to use opcodes as data then you can.

Any competent assembler programmer will be able to read and patch machine code too. Then ensure that the patch gets put into the source code and commented!!

Re: They don't come much more Vintage than this
 

I too first learned computing in CECIL, I was lucky to be selected to do 'computer programming' as a CSE at school, in 1978. The general consensus was 'why you doing that? you won't ever see a computer'!

Re: They don't come much more Vintage than this
 

My first programming was at Southampton U in 1974. They had an ICL mainframe, and I produced stacks of punched cards for programs I had written in Fortran and Algol. If you wanted more than 16k of core you had to have written permission from your supervisor (there was a maximum of 32k).

Rather later in 1979 I was writing optical design programs in BASIC to run on the Electronics department Modcomp, and later ported them into probably the first RM desktop. Two 8" floppy drives, one for the operating system and one for program and data.

In my first job in 1981 it was my task first thing to boot the PDP8. Several key entries got it to recognise the punched tape reader, which got it to recognise the washing machine size hard drive - and then the machine finally woke up.

I finally threw in the towel when object oriented programming came in in its various guises. My poor 1970's brain could not cope with that.

But I never formally programmed in assembler, although I did a bit just for fun in the early 80's.

Re: They don't come much more Vintage than this
 

By coincidence I am working on a late-ish PDP8 machine (PDP8/e) at the moment. So far I am doing battle to get the processor box mounted in the rack. Repairin the electronics, if it needs it, doesn't bother me at all.

I have the 'boot matrix' board in mine. A diode matrix ROM (I am not joking) that acts like the front panel amd loads the paper tape bootstrap into core. Means that starting up involves putting the loader tape into the reader and flipping one switch.

I am wondering what the 'washing machine size hard drive' was. PDP8 systems didn't generaly have large hard drives. The most common one (at least on later models) was the RK05, which is a single 6U rack unit taking a 14" disk cartridge which slides in through a door on the front. The cartridges were nicknamed 'pizzas' and the drives 'pizza ovens for obvious reasons.

I can't understand this modern very high level programming either. I'm a hardware guy. I think in terms of gates and flip-flops. Machine code is fine. Microcode (one level below machine code) is even better (and yes I have written microcode both in assembler and binary). I've never formally done any of it though (I failed computer studies O-level the only O-level I did fail).

Re: They don't come much more Vintage than this
 

Possibly a magnetic drum memory?

Re: They don't come much more Vintage than this
 

For quite a few years I used RK05s on various PDP-11s. I didn't know they were available for PDP-8 too. The 11/40 was booted by toggling a few opcodes in via the front panel switches. That somehow caused a jump to a boot ROM which knew about the RK05.