English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 06 November 2018, 23:11   #721
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 50
Posts: 1,049
Quote:
Originally Posted by Bruce Abbott View Post
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
Don_Adan is offline  
Old 07 November 2018, 00:01   #722
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by Don_Adan View Post
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.
plasmab is offline  
Old 07 November 2018, 00:13   #723
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 50
Posts: 1,049
Quote:
Originally Posted by plasmab View Post
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.
Don_Adan is offline  
Old 07 November 2018, 00:25   #724
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by Don_Adan View Post
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:
 

code: 
        lea .return_address,a4
        jmp my_subroutine
.return_address
This is because we have no stack. we use A4 as the stack. mostly.
plasmab is offline  
Old 07 November 2018, 02:35   #725
Don_Adan
Registered User
 
Join Date: Jan 2008
Location: Warsaw/Poland
Age: 50
Posts: 1,049
Quote:
Originally Posted by plasmab View Post
Yes. DiagROM and froniter.

In DiagROM i tend to do ...

Code:
 

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?
Don_Adan is offline  
Old 07 November 2018, 09:37   #726
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Quote:
Originally Posted by Don_Adan View Post
Why, no stack? No memory?

It has to run and diagnose things when ram is broken yes.
plasmab is offline  
Old 08 November 2018, 13:16   #727
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 561
Quote:
Originally Posted by Bruce Abbott View Post
Ahem...

CP/M

Quote:
Originally Posted by Don_Adan View Post
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
roondar is offline  
Old 08 November 2018, 21:28   #728
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 42
Posts: 3,085
Quote:
Originally Posted by plasmab View Post
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.

Quote:
Originally Posted by plasmab View Post
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.

Quote:
Originally Posted by plasmab View Post
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

Quote:
Originally Posted by plasmab View Post
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.
Thorham is offline  
Old 08 November 2018, 21:51   #729
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 45
Posts: 7,020
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!
Galahad/FLT is online now  
Old 08 November 2018, 21:58   #730
DH
Global Moderator

DH's Avatar
 
Join Date: Sep 2008
Location: Geordie Land
Age: 51
Posts: 4,082
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
DH is online now  
Old 08 November 2018, 22:11   #731
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 45
Posts: 7,020
Quote:
Originally Posted by DH View Post
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?
Galahad/FLT is online now  
Old 08 November 2018, 22:24   #732
DH
Global Moderator

DH's Avatar
 
Join Date: Sep 2008
Location: Geordie Land
Age: 51
Posts: 4,082
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
DH is online now  
Old 08 November 2018, 22:50   #733
dkedrowitsch
Registered User

 
Join Date: Nov 2018
Location: Boyertown, PA
Posts: 1
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?


Quote:
Originally Posted by DH View Post
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

Last edited by dkedrowitsch; 08 November 2018 at 22:58.
dkedrowitsch is offline  
Old 08 November 2018, 23:04   #734
Bruce Abbott
Registered User

Bruce Abbott's Avatar
 
Join Date: Mar 2018
Location: Hastings, New Zealand
Posts: 87
Quote:
Originally Posted by roondar View Post
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)
Quote:
The CP/M-86 .CMD file begins with a 128-byte header record:
Bruce Abbott is offline  
Old 08 November 2018, 23:12   #735
DH
Global Moderator

DH's Avatar
 
Join Date: Sep 2008
Location: Geordie Land
Age: 51
Posts: 4,082
Quote:
Originally Posted by dkedrowitsch View Post
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.

Quote:
Originally Posted by dkedrowitsch View Post
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.
DH is online now  
Old 09 November 2018, 10:24   #736
grond
Registered User

 
Join Date: Jun 2015
Location: Germany
Posts: 480
Quote:
Originally Posted by Bruce Abbott View Post
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...
grond is offline  
Old 10 November 2018, 11:57   #737
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 106
I've just finished my emotional article about processors - https://litwr.livejournal.com/3096.html

Quote:
Originally Posted by Don_Adan View Post
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,

Code:
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.

Quote:
Originally Posted by roondar View Post
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.


Quote:
Originally Posted by roondar View Post
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.



Quote:
Originally Posted by roondar View Post
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.

Quote:
Originally Posted by roondar View Post
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.
litwr is online now  
Old 10 November 2018, 12:21   #738
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,146
Quote:
Originally Posted by litwr View Post
I can only repeat that you can't make relocatable an instruction with two indices, for example,

Code:
MOV table(A0,D1),D2

Such instruction doesn't exist anyway! And if you need something like that
Code:
move.w table(pc,D1.w),D2


works wonders and is of course fully relocatable.





Quote:

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!
StingRay is offline  
Old 10 November 2018, 12:48   #739
litwr
Registered User

 
Join Date: Mar 2016
Location: Ozherele
Posts: 106
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.
litwr is online now  
Old 10 November 2018, 13:04   #740
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,238
Quote:
Originally Posted by litwr View Post
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 !).


Quote:
Originally Posted by litwr View Post
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 ?


Quote:
Originally Posted by litwr View Post
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.


Quote:
Originally Posted by litwr View Post
However 80386 can give 100% relocatability with built-in MMU too.
Every cpu with mmu can do this


Quote:
Originally Posted by litwr View Post
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.


Quote:
Originally Posted by litwr View Post
Sorry, I meant move.w (d8,a0,d1),d2.
Why the heck would we need this ?


Quote:
Originally Posted by litwr View Post
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.
meynaf is online now  
 


Currently Active Users Viewing This Thread: 2 (1 members and 1 guests)
meynaf
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Any software to see technical OS details? necronom support.Other 3 02 April 2016 13:05
2-star rarity details? stet HOL suggestions and feedback 0 14 December 2015 06:24
EAB's FTP details... Basquemactee1 project.EAB File Server 2 30 October 2013 23:54
req details for sdl turrican3 request.Other 0 20 April 2008 23:06
Forum Details BippyM request.Other 0 15 May 2006 01:56

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:33.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.29339 seconds with 16 queries