68k details

[plasmab]

Originally Posted by grond

Well, ldm, stm, mul and divs all do well with microcode. Not much but not nothing either. Thanks God or rather Sophie Wilson that they did use microcode and not insist on the programmer using a bunch of primitive instructions to implement these instructions in macrocode...

I think MIPS and also the earlier SPARC required the programmer to use a sequence of shift-add/subtract instructions in order to make multiplications and divisions.

IIRC Sophie had a bit of a sulk (overstating for effect) about DIVS being in there at all. It wasn’t there on ARMv1. She was also pretty against the FPA ... I have one of those too in my A540

[ Show youtube player ]

See from around 7 mins in. Notice that ARM is referred to as the Acorn RISC Machine.

Sophie always seemed pathologically against having anything complex in the chip. Rightly or wrongly

[grond]

Well, then thanks to Sophie for giving in...

[Bruce Abbott]

Originally Posted by litwr

Indeed, systems with 486@25MHz or 68040@20MHz were faster than ARM based at 12MHz but their prices at 90 or 91 were above $10000.

So we are comparing whole systems now?

The CPU is usually only a small part of the total cost. High-end systems generally get the latest CPUs first because they need the power and price doesn't matter, but prices soon tumble once consumer machines get them. By 1992 'high-end' 486 clones were selling for under $2000. In 1993 the Macintosh LC 475 was priced at $1085.

Originally Posted by plasmab

The Acorn A4000 was a 12Mhz ARM250. It was released in 1992 and it cost 999 GBP. I have one of these machines.. Very simple.. IDE interface on board. Max 4Mb ram.

I had an A3010 and compared to my Amigas it sucked. The CPU might have been more powerful, but you would never know it because the rest of the system was frustratingly under powered. And I couldn't get any software for it, so what was the point?

All this arguing about whether x or y CPU was more powerful or cost less per mip is silly. A CPU by itself is worthless. It's the other parts of the system - RAM, ROM, chipsets, storage devices, OS, application software - that make the difference. If you are comparing systems then everything must be considered, not just the CPU.

[plasmab]

Originally Posted by Bruce Abbott

I had an A3010 and compared to my Amigas it sucked. The CPU might have been more powerful, but you would never know it because the rest of the system was frustratingly under powered. And I couldn't get any software for it, so what was the point?

Which part of the "system" was slow? My only frustration with the ARM250 series was they were limited to 4Mb of Ram and they could only use the first 512K as "chip" ram. The IDE interface was buffered and performed better than the A1200, the DMA had better throughput. It could do 1Mhz sound (yes 1MHZ) and happlily does VGA resolutions. So i'm confused about what was slow?

The number of games ported was lower i guess.

EDIT: if you still have that A3010 i'll buy it from you. it has one of the best TV modulator circuits i've ever seen.

[roondar]

Originally Posted by litwr

It is completely untrue. It was meynaf who used high level OS calls to make 68k code smaller. So he used a call to OS routines while I had to use codes for those routines which doesn't present in DOS. Then I rewrote my code eliminating some service auxiliary functions making the condition more equal for the both platforms.

It is actually 'completely' true: I was referring to your use of a .COM file to make your executable size smaller on one specific architecture. That is using OS features to make your code appear smaller than it really is and has absolutely nothing to do with comparing the strength of ISA's.

As for using OS calls, IIRC both of you agreed to not use those any more. As such, I didn't feel it needed to refer to them.

Originally Posted by litwr

Indeed, systems with 486@25MHz or 68040@20MHz were faster than ARM based at 12MHz but their prices at 90 or 91 were above $10000. We can introduce new measurement - a performance unit per dollar. With it ARM systems were much better too.

Indeed, Intel's 486 and Motorola's 68040 were faster. To be clear here, they were roughly 3-4x faster than the ARM you are talking about. They were also a whole lot cheaper than you claim.

A 25MHz 486 from april 1991 (see https://books.google.nl/books?id=0FA...201991&f=false) could be bought for $3000.

Four times faster, but only about 1.7 times more expensive (yeah, I forgot to use the exchange rate between pounds and dollars - April 1991 puts it at 1.7 pounds per dollar, so the GPB 999 A3010 would be $1698). Seems Intel wins this round

Note that a fast 386 or 68030 should also comfortably beat the 12MHz ARM2. And those were cheaper still.

[plasmab]

Originally Posted by roondar

Four times faster, but only about 1.7 times more expensive (yeah, I forgot to use the exchange rate between pounds and dollars - April 1991 puts it at 1.7 pounds per dollar, so the GPB 999 A3010 would be $1698). Seems Intel wins this round

Note that a fast 386 or 68030 should also comfortably beat the 12MHz ARM2. And those were cheaper still.

The Acorn machines were never cheap. They were really really expensive.

The fact that anyone is even comparing chip designed by two British guys with no funding against the 030s and x86s of this world is amazing.

For me this is when the ISA was picked up and built in a professional way

https://en.wikipedia.org/wiki/StrongARM

It was a little late to win the PC battle of the 90s for sure... but its one amazing chip that keeps giving the more you study how to use it.

It confuses me that the optimization fanatics arent more in love with it because its got more secrets to unlock than the 68000. Which I also love.

[roondar]

Originally Posted by plasmab

The Acorn machines were never cheap. They were really really expensive.

The fact that anyone is even comparing chip designed by two British guys with no funding against the 030s and x86s of this world is amazing.

For me this is when the ISA was picked up and built in a professional way

https://en.wikipedia.org/wiki/StrongARM

It was a little late to win the PC battle of the 90s for sure... but its one amazing chip that keeps giving the more you study how to use it.

It confuses me that the optimization fanatics arent more in love with it because its got more secrets to unlock than the 68000. Which I also love.

I think it may have to do with the somewhat different style of assembly language. I've looked into ARM2 myself at one point (I wanted to see the precursor to what's powering my iPhone ) and found the code to be harder to read than that of other processors for some reason.

Also, the 1990's was the era in which people slowly transitioned away from doing everything in assembly to begin with, so the timing might also play a role here.

[Bruce Abbott]

Originally Posted by plasmab

if you still have that A3010 i'll buy it from you. it has one of the best TV modulator circuits i've ever seen.

Unfortunately I had a big cleanup and threw it out. Who knew that in a few short years all that old junk would become 'vintage' and highly sought after!

[meynaf]

Originally Posted by litwr

Sorry but you have used unfair tricks again.

That's the pot calling the kettle black...
Who uses tricks ? Code for time measurement is larger on the Amiga !
So we both can just remove it.

Originally Posted by litwr

My spigot implementation claims that it is the fastest but to prove this it requires a timer result. You have cut it! So you code have proved nothing.

Who started cutting ?
Sorry, but your 80386 code appears to have non-working timer code. Where is the text for the message saying what time it took ?
Furthermore, i never said this version was the fastest anymore. I never said it still measured time anymore. No OS calls, we said. I'm just approaching this goal.

Originally Posted by litwr

The 80386 is still unbeaten.

I wouldn't say that, no. It's unbeaten only because you constantly change the rules.
However, even with whatever rules you use, it would be largely beaten if using my own "reencoded from 68k" instruction set

Originally Posted by litwr

With the help of ARM experts I have just improved my codes for the ARM's line drawing routine.

Showing ARM code here is a very good idea. Now we're talking on something concrete (even thouth it's still just a single, small example).

Originally Posted by litwr

It is only 88 bytes now! The 80386's routine takes 84. ARM code uses only one jump but 80386 and 68000 codes - 7.

Best is still 72 bytes, and i didn't make that much efforts to reduce it.

Originally Posted by litwr

So ARM has quite good code density when it is programmed properly.

Please do not draw generalities from a single example.

Originally Posted by litwr

It is also notable that one assembly line almost always corresponds one line in the C-source code. What a beauty!

There is no beauty for me in C code, and therefore no beauty to whatever corresponds to it.

Originally Posted by litwr

BTW I have tested this code with my Raspberry Pi so it is 100% correct.

Seems we just have to trust you on this, hmm ?

Originally Posted by litwr

I have checked the 386 code and without timer support it can be less than 180 bytes. BTW I have published the code for 80286 by a mistake, the fair code for 386 is less than 386 bytes.

This means timer support would be more than half the code, quite irrealistic.
And that's a claim without proof. You're quite fast saying that for others, but you do the same now :/

Originally Posted by litwr

English is very tough. IMHO nobody knows it perfectly even the native speakers!

For me English is too simple, imprecise language. In short, not the right tool - but what else can we do.

Originally Posted by litwr

With help I have made other improvements to ARM code - it is only 80 bytes now - it is less than the code for 80386 and close to size size of 68000 codes (72 bytes)!

Come on, more efforts on the "true" 80-byte version (2 insns to remove) and it could equal the 68k version
Could you please post the 80386 code here as well ?

[Megol]

Originally Posted by grond

Well, ldm, stm, mul and divs all do well with microcode. Not much but not nothing either. Thanks God or rather Sophie Wilson that they did use microcode and not insist on the programmer using a bunch of primitive instructions to implement these instructions in macrocode...

DIVS? ARM added integer division after 2010 IIRC, don't think microcode is involved.

I think MIPS and also the earlier SPARC required the programmer to use a sequence of shift-add/subtract instructions in order to make multiplications and divisions.

MIPS used an ugly hack for integer multiplication as it didn't fit into the ordinary pipeline but it was there. SPARC used the FPU IIRC which wasn't too unusual at the time or even now (for integer division).

[plasmab]

Originally Posted by Megol

DIVS? ARM added integer division after 2010 IIRC, don't think microcode is involved.

Ah yes. ARMv1 doesn’t even have a MUL. ARMv2 got MUL but it’s 16x16=32 bit only.

Some assemblers take DIVS as a mnemonic but they emit 10 or so instructions.

[grond]

Originally Posted by Megol

DIVS? ARM added integer division after 2010 IIRC, don't think microcode is involved.

Yes, your are right.

SPARC used the FPU IIRC which wasn't too unusual at the time or even now (for integer division).

No, here you are wrong. I just looked it up. SPARC had the "MULScc" instructions which -- contrary to what its name seems to imply -- does not do a whole multiplication but just a single step in (IIRC) a shift-add multiplication. The mnemonic "MULS" stands for "MULtiply-Step". This instruction has been superseded by SMUL and UMUL instructions, of course.

https://docs.oracle.com/cd/E19120-01...172/index.html

[zero]

I was impressed by how powerful the Archimedes machines were. The BASIC interpreter was damn fast, and if you got into C/assembler the chunky screen mode was very fast for stuff like line/polygon drawing.

Where it tended to suck was stuff like scrolling.

[Megol]

Originally Posted by grond

No, here you are wrong. I just looked it up. SPARC had the "MULScc" instructions which -- contrary to what its name seems to imply -- does not do a whole multiplication but just a single step in (IIRC) a shift-add multiplication. The mnemonic "MULS" stands for "MULtiply-Step". This instruction has been superseded by SMUL and UMUL instructions, of course.

Thanks for the correction. That's an ugly instruction for something intended to be a Scalable Processor ArchiteCture.

Originally Posted by zero

I was impressed by how powerful the Archimedes machines were. The BASIC interpreter was damn fast, and if you got into C/assembler the chunky screen mode was very fast for stuff like line/polygon drawing.

Where it tended to suck was stuff like scrolling.

Vertical scrolling is supported directly, horizontal can be done by manipulating borders.

[roondar]

The lack of scrolling prowess for the Acorn with it's ARM2 (as well as machines using 68030's, 386's etc) has always caused me some wonder. These processors should be plenty fast enough to do the whole thing in software and still easily make a 50/60Hz update rate.

A quick back-of-the-envelope calculation suggests that the ARM2@8MHz should be able to smoothly scroll a 320x256, 256 colour screen using no more than about 50% of the CPU time it has. That still leaves quite a bit of bandwidth/CPU power for softsprites, game/demo logic and the like.

Perhaps it has more to do with the interface into graphics memory?

[plasmab]

Originally Posted by roondar

The lack of scrolling prowess for the Acorn with it's ARM2 (as well as machines using 68030's, 386's etc) has always caused me some wonder. These processors should be plenty fast enough to do the whole thing in software and still easily make a 50/60Hz update rate.

A quick back-of-the-envelope calculation suggests that the ARM2@8MHz should be able to smoothly scroll a 320x256, 256 colour screen using no more than about 50% of the CPU time it has. That still leaves quite a bit of bandwidth/CPU power for softsprites, game/demo logic and the like.

The ARMv2 is plenty fast enough to update every frame.. and the barrel shifter makes pixel level scrolling free. see axis as an example game. Amiga coders want hardware way to do it. They don’t like to use their brain.

EDIT: you can preload the MEMC video DMA register ahead of time so it latches on vsync. That’s free veritical scrolling. IIRC You can even poke the VIDC start window regs to get 2 pixel res horizontal scrolling for free.

Yes.. 2 pixel res scrolling.

http://chrisacorns.computinghistory...._Datasheet.pdf

[roondar]

Originally Posted by plasmab

The ARMv2 is plenty fast enough to update every frame.. and the barrel shifter makes pixel level scrolling free. see axis as an example game.

As I thought then, it can be done.

Amiga coders want hardware way to do it. They don’t like to use their brain.

[grond]

If the CPU does the scrolling, you need the required mem bandwidth to a) read the screen data, b) write it back and then c) read it through video DMA. If the video hardware can scroll by itself, you only need c). Three times less memory impact, I still think the Amiga way is quite clever.

[plasmab]

Originally Posted by grond

If the CPU does the scrolling, you need the required mem bandwidth to a) read the screen data, b) write it back and then c) read it through video DMA. If the video hardware can scroll by itself, you only need c). Three times less memory impact, I still think the Amiga way is quite clever.

You still need a write the buffer in the first place though. You do the shift as you create the scene. You don’t render, read, shift, write. Like I say... if you use your brain up front the result is the same.

The Amiga way just means you don’t have to think.

[tolkien]

So all amiga custom chips are not usefull and we should use only the cpu power to do all kind of things.