Programming in assembler?

I believe you've just outed yourself as an ex Acorn-er. I don't remember any other BASICs having such a thing :)

--
W J G
Reply to
Folderol
Loading thread data ...

Actually an ex-Apple II-er. 4 years before the BBC Micro. My BASIC has 'nods' to both in little ways e.g. supports BBC envelope command, etc. and Apple II plot/line commands and "low-res" graphics to a degree...

Gordon

Reply to
Gordon Henderson

It's not that there's anything wrong with 6502 but I really hated it. I think this was because of the project I was doing rather than the instruction set. Also I'd just done a lot of 68k code and it did spoil you when you came back to the 6502. I prefered the 6303 over the 6502 TBH.

Reply to
mm0fmf

Of course! Its your own project and IIRC, is written in C. Besides, I'd argue that, with [gasp] structured programming and no line numbers it may be Basic but its not BASIC!

That is optional. FWIW my favourite assembler is/was MACE/XMACE (an integrated editor+assembler for the 6809. It was fast, seeing that it was single pass with both source and generated binary being in RAM. XMACE was a cross-assembling version of MACE that generated 6800 binaries.

Embedding assembler in a PL/9 program was also fun. PL/9 was an implementation of PL/M for the 6809, but a bit pointless since the code PL/9 generated was very tight.

Like MACE, PL/9 was an integrated editor+compiler+debugger and was almost as fast as MACE, being a single pass compiler and again, the source and compiler output were were both in RAM, though of course it could read library code from disk at compile-time, though with a speed penalty.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

The 6502 was an "R" computer. Not "RISC", just "reduced". 3510 transistors for 56 instructions (155 opcodes) is just amazing, as well as the asynchronous design.

But it remains a reduced computer.

I have to go into "6502 mode" mentally when I am to program one, kind of entering a shrunk world.

-- mrr

Reply to
Morten Reistad

Z80 and 6502, you say? 15 MB pdf:

formatting link

Reply to
A. Dumas

Utter nonsense, ARM is one of the easiest instruction sets to learn.

Exactly.

---druck

Reply to
druck

You forgot 6502. 68xxx was ok, but the operands were reversed from ARM/6502 ordering.

---druck

Reply to
druck

has it been since the 1990's ?

formatting link

--
--
Reply to
Björn Lundin

I don't recall using assembler professionally since the late '70s.

I wrote a lot of 6809 and 68xxx assembler for private projects in the late '70s and '80s, but even these were mostly PL/9 by 1990 and since then almost entirely Sculptor (a 4GL), C and Java.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

That was almost as contentious as vi/emacs at one point.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:>WIN                                      | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

I think the reality is that an overage programmer will produce faster and smaller code in a higher level language like C, but a really good programmer looking to absolute go to the bleeding edge can in the end do better in assembler.

--
?But what a weak barrier is truth when it stands in the way of an  
hypothesis!? 
 Click to see the full signature
Reply to
The Natural Philosopher

I was writing it for embedded stuff and deep OS fiddling up to the late 80s.

Bare metal coding usually needs a bit.

Indeed. Commercially unless its massive volume, the cost of programmers getting used to a new instruction set or a new set of assembler tools is a lot higher than porting the C complier to a new architecture.

That was really the genius of Kernighan and Ritchie. To create the minimal level of abstraction above assembler to ensure portability, and then write the minimal operating system to meet their actual needs using it.

--
Canada is all right really, though not for the whole weekend. 

"Saki"
Reply to
The Natural Philosopher

I've written assembler for a number of computers including some device drivers, and I can't agree with "FUN"! Yes, you can learn something about the hardware and, yes, you can shave off a few cycles, but I think that even for an amateur the time could be better spent. Worth doing it once to learn, though.

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

On 26/08/2016 10:22, The Natural Philosopher wrote: []

But can "do much better" by careful tuning of the algorithms. Profile the problem program to check - see where all the time is being spent. No to mention the much faster development time.

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

That's part of it. But its not the only part of it.

In the end (wo)men wrote the compiler optimisation, and sometimes another (wo)man can beat it.

--
If I had all the money I've spent on drink... 
..I'd spend it on drink. 
 Click to see the full signature
Reply to
The Natural Philosopher

True, but even more important IMO was to split the compiler into four separate, independently-executable modules (preprocessor, compiler, assembler and linker) because that made cross-compilation and hence porting the compiler much easier:

repeat { 1) Replace the compiler back-end to generate assembler for the new target system. Adapt the assembler to process the target system's assembler and the linker to process the target system's binary

2) Run preprocessor and new compiler on existing host, to generate assembler files for itself + libraries 3) Take resulting assembler to new system, compile and link with native assembler and linker. 4) Test complete C compiler on target system } until C compiler runs successfully
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

Very fair point.

Actually probably the most important factor was that neither of them were 'computer scientists'. Kernighan was an engineer and Ritchie was a mathematician and physicist.

--
If I had all the money I've spent on drink... 
..I'd spend it on drink. 
 Click to see the full signature
Reply to
The Natural Philosopher

The real magic is in the optimiser section. Graham Trott's PL/9 compiler proves that point: it was a combined editor/compiler/debugger for a version of PL/M on the 6809 and, amazingly would run in 48K RAM - amazing because that 48k included buffers for a complete source file and the compiled and runnable output.

PL/9 is a similarly sized language to C. It didn't have an optimiser but generated really tight code: I never found it worthwhile to hand- optimising the assembler it generated for a single statement. However, since there was no optimiser, each statement was pretty much stand-alone code, e.g. in int x; x = a * b; z = x * offset;

the first assignment statement saved the result (in reg D) into X and the second one retrieved it into reg D, so in theory anyway it could be optimised by removing the initial LDD instruction from the second assignment statement. However, in practise the benefits were small because the saving you got was under one instruction per statement.

I think the only big savings I ever made were in long loops the manipulated strings and even there the optimisation effort tended to be out of proportion to the effort applied.

I think this discovery applies in general to the output from almost all modern HLL compilers: if hand optimisation is of any use at all it will be inside the inner loop and even there is only worthwhile if the code therein is complex. Optimisation of code in outer loops is just pointless.

In case you're wondering, I've used PL/9 rather than C code for this example because I am (or was) much more familiar with the code it generates than the output of any C compiler I've used: the Microware C compiler (on 68xxx) wasn't an optimising compiler and its code was always 'fast enough' for my purposes. I don't understand either X86 or ARM assembler as output by the C compilers I've used on this hardware.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

to:

Yeah, as of today, writing something completely in assembler is just stupid . Inline assembler on the other hand could be useful, to squeeze some speed o ut of the processor, or to use some processor features that the C compiler is not able to use...

Bye Jack

Reply to
jack4747

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.