68k details

[Don_Adan]

Originally Posted by Bruce Abbott

Ahem...

CP/M

Seems to be perfect OS for comparing real size of Pi routine. Same OS calls will be used, same executable file format.

BTW. Especially for plasmab, I forget about a few hacky (for me) version, but more readable perhaps version. Used sometimes inside some programs. Good f.e for programs with more than 32K and less than 64K. Even in Amiga ROM modules.

bsr.w Skip1
rts

; up to 32k code/data here

Skip1
bra.w Skip2

; up to 32k code/data here

Skip2
bra.w Skip3

; up to 32k code/data here

Skip3
bra.w Skip4

; up to 32k code/data here

Skip4
moveq #0,d0
rts

[plasmab]

Originally Posted by Don_Adan

BTW. Especially for plasmab, I forget about a few hacky (for me) version, but more readable perhaps version. Used sometimes inside some programs. Good f.e for programs with more than 32K and less than 64K. Even in Amiga ROM modules.

You know i actively contribute to DiagROM right? I'm happy with doing things the hacky way. I just have guilt for it.

[Don_Adan]

Originally Posted by plasmab

You know i actively contribute to DiagROM right? I'm happy with doing things the hacky way. I just have guilt for it.

No, i dont resourced DiagROM code. I mean about original Amiga ROM modules. Anyway, very rare exist 68k program written in 68k ASM and bigger than 100k.

[plasmab]

Originally Posted by Don_Adan

No, i dont resourced DiagROM code. I mean about original Amiga ROM modules. Anyway, very rare exist 68k program written in 68k ASM and bigger than 100k.

Yes. DiagROM and froniter.

In DiagROM i tend to do ...

 

code: 
        lea .return_address,a4
        jmp my_subroutine
.return_address

This is because we have no stack. we use A4 as the stack. mostly.

[Don_Adan]

Originally Posted by plasmab

Yes. DiagROM and froniter.

In DiagROM i tend to do ...

 

code: 
        lea .return_address,a4
        jmp my_subroutine
.return_address

This is because we have no stack. we use A4 as the stack. mostly.

Why, no stack? No memory?

[plasmab]

Originally Posted by Don_Adan

Why, no stack? No memory?

It has to run and diagnose things when ram is broken yes.

[roondar]

Originally Posted by Bruce Abbott

Ahem...

CP/M

Originally Posted by Don_Adan

Seems to be perfect OS for comparing real size of Pi routine. Same OS calls will be used, same executable file format.

I'm not so sure about that, CP/M-68K seems to have extra features in the executable format to allow for sections, etc (see here: https://www.google.com/url?sa=t&rct=...IbvCI3Zv5nrdnB). AFAIK CP/M-86 does not do this.


Apologies for the 'Google link', but I can't seem to get a direct link out of Google

[Thorham]

Originally Posted by plasmab

That will work. Rather hacky. but it will work. I guess you'd use it very sparingly.

That isn't hacky in any way shape or form. In assembler you never have an instruction for every single thing you can think of, so you have to use constructions. Think about it this way: Is a C style for loop written in assembly language a hack because there's no instruction or addressing mode for it? Of course not.

Originally Posted by plasmab

The previous code example did pointer arithmetic to get the correct address.

Pointer arithmetic in assembler is not hacky at all, it's absolutely essential to writing assembly code.

Originally Posted by plasmab

Disabling the OS is usually a sign of a hack right there. I wrote 68k games as a teenager using this method. It’s pretty much the definition of bad coding.

It completely depends on the context. If you're developing a game for an A500 with 1MB memory, then memory is tight and the OS uses CPU time. Not always a good thing for games. For applications it's still true, of course.

That said, I only write OS friendly stuff

Originally Posted by plasmab

Another massive hack is incbin. I read that as “I’m too lazy to load something from disk properly”

Again, it depends. If you have some small data, then it's probably nicer to embed it into the executable (data segment!), because now you have one file with no dependencies. If you have a lot of data and you simply incbin EVERYTHING, then sure, it's crap.

[Galahad/FLT]

Also another reason for incbin not being lazy is in part the crap block allocation on the PC hard drive systems.
Having lots of small files that are smaller than the smallest block size the PC can cope with leads to LOTS of wasted room where a game takes up more space than necessary, which obviously years ago was a no-no with the cost of hard drives.

But the prospect of loading lots of little files will overly extend a loading sequence, not shorten it.

Its hardly "hacky" to improve the end user experience.

EDIT: Ah, this might all be rather moot now, Plasmab appears to be banned!

[DH]

Before anybody starts jumping the gun on his ban, read this http://eab.abime.net/showthread.php?...68#post1283468 then maybe if it's worth continuing, keep it on topic please

[Galahad/FLT]

Originally Posted by DH

Before anybody starts jumping the gun on his ban, read this http://eab.abime.net/showthread.php?...68#post1283468 then maybe if it's worth continuing, keep it on topic please

I'm just pointing out he's banned, i'm sure the reasons for doing so aren't being called into question

What exactly did he do?

[DH]

I know you aren't Galahad, I'm simply stopping something that might start. He deleted every single post of his on EAB and I've had the misfortune of restoring all of his 2500+ posts.

There's more to it than that, but this is not the place for that discussion.

Continue as you were all

[dkedrowitsch]

A huge thanks for your effort of restoring those deleted posts. There's a wealth of valuable knowledge in his posts, I'm glad they weren't lost for good.

But why is the TF530 thread locked? What about those besides Steve who are still actively working on and wish to contribute to the project?

Originally Posted by DH

I know you aren't Galahad, I'm simply stopping something that might start. He deleted every single post of his on EAB and I've had the misfortune of restoring all of his 2500+ posts.

There's more to it than that, but this is not the place for that discussion.

Continue as you were all

[Bruce Abbott]

Originally Posted by roondar

I'm not so sure about that, CP/M-68K seems to have extra features in the executable format to allow for sections, etc.

CP/M-68K executable files appear to have a 12 byte header specifying the size of the code, data, and bss sections. That's much smaller than the minimum of 36 bytes in an Amiga executable. Also the sections are contiguous, so a buffer can be created in bss and referenced pc relative, saving a few more bytes. BDOS calls are made via Trap#2, similar to x86.

So despite having a small header CP/M-68k is a fairly close match to MSDOS, and therefore perhaps a fair comparison?

However CP/M-86 would not be, because...

CP/M-86 executables (.CMD)

The CP/M-86 .CMD file begins with a 128-byte header record:

[DH]

Originally Posted by dkedrowitsch

A huge thanks for your effort of restoring those deleted posts. There's a wealth of valuable knowledge in his posts, I'm glad they weren't lost for good.

Thanks and indeed there is, this is why EAB added this security measure, if that's what you can call it.

Originally Posted by dkedrowitsch

But why is the TF530 thread locked? What about those besides Steve who are still actively working on and wish to contribute to the project?

You'll need to ask Jope as it's his forum and I wouldn't want to overstep the mark with regards to something I have very little knowledge about

OK all, back on topic please, if you have anything to say about the matter you can PM me or one of the other mods/GM's, but no more in this thread please.

[grond]

Originally Posted by Bruce Abbott

However CP/M-86 would not be, because...

CP/M-86 executables (.CMD)

Well, that is certainly due to some shortcoming of the x86 ISA when compared to the 68k ISA...

[litwr]

I've just finished my emotional article about processors - https://litwr.livejournal.com/3096.html

Originally Posted by Don_Adan

Every 68k Amiga code stored fully in chip or fast memory can be fully relocatable.

I can only repeat that you can't make relocatable an instruction with two indices, for example,

MOV table(A0,D1),D2

The idea of 100% relocatable code for 68k or PDP-11 is a kind of chimeric one. You can do it on the purpose but generally it is bigger and slower. Thus above 99.9999% of 68k programs do not consist of 100% relocatable code. But 8086 gives you an opportunity to use 100% relocatable code just limiting us with its size: we have to use less than 64 KB for codes, 64 KB for data, 64 KB for a bit slower extra data and 64KB for stack. With 80386 you can expand 64 KB up to 4 GB and get two additional segments for extra data but this is not supported by DOS directly. However 80386 can give 100% relocatability with built-in MMU too. So COM-format is the demonstration of x86 ISA superiority. It should be absolutely clear now.

Originally Posted by roondar

Don't be silly now, litwr clearly never accepts anything that supports the 68000 as being as good or better than 8086 as he has determined that any such information is clearly biased nonsense. Obviously, only articles that detract from the 68000 and praise Intel are accurate and the rest should be ignored

Thank you for sharing you opinion but it is not true.

Originally Posted by roondar

A couple of things about your list:
1) you forgot to mention the 68040 result, which is significantly higher than the 80486 result. It scores 21 MIPS in your list (see manufacturer Motorola).

3) the 486 result seems really low, I have seen claims of 20 MIPS@25MHz elsewhere. Which would make some sense as this chip was seen to be competitive with the 68040 and that clearly wouldn't have been the case if it ran upwards of 30% slower.

However, it doesn't really matter anyway, as the claim that the 12MHz ARM2 was competitive with a 25MHz 486 is still plainly false.

They show the ARM2@12MHz is at best 45% of the speed of a 25MHz 486. Or, perhaps easier to grasp, the 486 is at least 2x the speed of the ARM2.

Calling that difference 'a bit slower' is disingenuous at best.

They also show that the ARM2@12MHz is slower than both the 386@33MHz and the 68030@33MHz (let alone one at 50Mhz). Which conforms exactly to what I stated at the start of our little exchange about the ARM2.

The article you linked through also supports my position and not yours as it claims that the ARM2@8MHz challenges, but does not always beat, a 16MHz 386 at integer tasks. And loses at floating point heavy tasks & sorting. Extrapolating that to a 33MHz 386 and a 12MHz ARM2 would give you a 50% bonus for the ARM, but a 100% bonus for the 386 => the 33MHz 386 should be faster and that is exactly what we already knew from the tables above.

Even if you look at the rather impressive Dhrystone results of the ARM2@8 vs the 386@16, scaling these up to 12 and 33 MHZ still has the ARM2 lose.

In other words, the evidence you managed to find does not support any of your claims and in fact supports everything I've said, but you're going to continue claiming your earlier opinions are probably correct anyway. Got ya.

Sorry I really knows little about 68040. I know only that it was not used so widely as 80486, it had lower frequencies, problem with FP, ... I can add that it was used surprizingly rarely and was eventually replaced by PowerPC. So it showed some very serious shortcomings that prevented its success. Maybe it was also too costly. In the list 68040@25MHz shows about 17.5 MIPS on average, 80486@25MHz gives slightly more but the difference is rather insignificant.

I have only claimed that ARM@25MHz can be faster that 80486@25MHz.

Indeed, the official benchmark shows that 80386@33MHz is faster that ARM@12MHz. However they sometimes used Acorn's Basic against C-compilers at x86! My experience with ARM let me say that ARM allows to write very compact and fast codes which are much better than codes generated by compilers of the 80s or even 90s.

Originally Posted by roondar

And seriously, approximate cycle counts for an untested bit of code? What use are those exactly (I mean, exact cycle counts might be useful, but approximate seems rather useless)? And what exactly does one tiny algorithm prove? (answer: nothing, really! It might be an outlier and considering other benchmarks disagree with these results, it is actually likely that it is an outlier)

Why do you call line drawing code untested? It is fully tested for x86, 68k and ARM. I have made very accurate cycle counting, anybody may check it. The code is rather short it will take only less than 10-15 minutes. I said "on average" because the codes have conditional instructions which timings depend on condition. I took 50-50 in those cases.

Originally Posted by roondar

And all of this is without accounting for the fact we're comparing the wrong CPU's. As I researched (ok, Googled ) this post, I found the 1991 Archimedes at GBP999 was not running a 12MHz ARM2. It was in fact the A5000 running a 25MHz ARM3*. Which indeed gets a lot closer to the 486/68040 running at the same speed, although the ARM3 MIPS rating is still clearly lower than either of these two.

However, the given price of the A5000 did not include a hard disk or monitor, where the 486 I quoted did have a monitor and hard disk. As such, I'm still not convinced about the price/performance ratio being in the Acorns favour.

*) The 12MHz variation seems to be the A3010, which was released in 1992 for GBP499. There may in fact be other 12MHz variants prior to 1991, but the information on what is actually in the the various Archimedes models is somewhat scarce. However, even if they did exist, all potential candidates prior to 1991 were a lot more expensive than the GBP999 A5000.

IMHO the UK computer market was stormed by NA companies. Commodore sold 2-3 times more Amigas in the UK than in the gigantic NA market. Olivetti provided poor management and refused to use their trade net to sell Archimedes. And there was IBM PC factor too. So Acorn did rather very well and produced very good computers in those circumstances. I met an Archimedes with 8MHz ARM-2 in 1991, I was very impressed by its performance. It was more 10 times faster than my Amiga 500. Indeed sound and graphics of A500 was approximately at the same level.

[StingRay]

Originally Posted by litwr

I can only repeat that you can't make relocatable an instruction with two indices, for example,

MOV table(A0,D1),D2

Such instruction doesn't exist anyway! And if you need something like that

move.w table(pc,D1.w),D2

works wonders and is of course fully relocatable.

The idea of 100% relocatable code for 68k or PDP-11 is a kind of chimeric one. You can do it on the purpose but generally it is bigger and slower.

That's wrong for 68k at least! In some(!) cases relocatable code can be slower/bigger but in most of the cases it is faster and shorter!

[litwr]

Sorry, I meant move.w (d8,a0,d1),d2.
BTW I have just made 68000 cycles count for a standard line bresenham algorithm implementation by meynaf which shows the best code density. It is 70. 80386 takes 52, 80486 - 24, and ARM - 16. In my previous post I wrote 14 for ARM by a mistake. It is interesting to get 68020 timing. Please help with it. BTW I didn't count cycles for return from subroutine.

[meynaf]

Originally Posted by litwr

The idea of 100% relocatable code for 68k or PDP-11 is a kind of chimeric one. You can do it on the purpose but generally it is bigger and slower. Thus above 99.9999% of 68k programs do not consist of 100% relocatable code.

This is not true. A lot of 100% position-independent exists (don't say relocatable, it's wrong word for this !).

Originally Posted by litwr

But 8086 gives you an opportunity to use 100% relocatable code just limiting us with its size: we have to use less than 64 KB for codes, 64 KB for data, 64 KB for a bit slower extra data and 64KB for stack.

Did you know 68k can do the same, and without the shortcomings ?

Originally Posted by litwr

With 80386 you can expand 64 KB up to 4 GB and get two additional segments for extra data but this is not supported by DOS directly.

For this you need big hacks such as DOS4GW. Obviously DOS couldn't support this horror.

Originally Posted by litwr

However 80386 can give 100% relocatability with built-in MMU too.

Every cpu with mmu can do this

Originally Posted by litwr

So COM-format is the demonstration of x86 ISA superiority. It should be absolutely clear now.

What superiority ? This is nonsense.
COM is limited to 64k, this rather shows how inferior x86 is. And COM isn't supported anymore today.
Any decent CPU, even ARM, can do position-independent code.
What's absolutely clear is that you're strongly biased in favor of x86.

Originally Posted by litwr

Sorry, I meant move.w (d8,a0,d1),d2.

Why the heck would we need this ?

Originally Posted by litwr

BTW I have just made 68000 cycles count for a standard line bresenham algorithm implementation by meynaf which shows the best code density. It is 70. 80386 takes 52, 80486 - 24, and ARM - 16. In my previous post I wrote 14 for ARM by a mistake. It is interesting to get 68020 timing. Please help with it. BTW I didn't count cycles for return from subroutine.

I find counting cycles for non time-critical code rather pointless (but divide 68000 timing by 2 to get an idea of what it could look like).
Why don't we do a c2p/p2c rather ? It would be fun to see some x86 or arm version.