English Amiga Board


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

 
 
Thread Tools
Old 20 August 2018, 16:57   #41
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Quote:
Originally Posted by Leffmann View Post
Meynaf, you're drunk. Turn the computer off and go to bed.
Nope, I don't drink. But i notice you're now doing personal attacks.
meynaf is offline  
Old 20 August 2018, 17:04   #42
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,201
No it's not a personal attack There's a complete desktop operating system written entirely in x86 machine language. You can deny it all you want, but it won't change anything
Leffmann is offline  
Old 20 August 2018, 17:05   #43
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 644
Quote:
Originally Posted by meynaf View Post
Finally !
So it appears to be real asm.
Well, but that's not exactly "a whole OS", rather a small vm.
That is not the OS source code, that is code for some small applications.

The full code (for the 32 bit version) can be found here: https://github.com/marcosptf/menueto...el-sources-32b

I've never used this OS by the way, but I got interested by this thread and googled around a bit
roondar is offline  
Old 20 August 2018, 17:11   #44
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Quote:
Originally Posted by Leffmann View Post
No it's not a personal attack There's a complete desktop operating system written entirely in x86 machine language. You can deny it all you want, but it won't change anything
You call that complete ? Have a look at the API list ! They don't even have support for basic memory allocation !
(And perhaps at the list of supported machines as well.)


Quote:
Originally Posted by roondar View Post
That is not the OS source code, that is code for some small applications.

The full code (for the 32 bit version) can be found here: https://github.com/marcosptf/menueto...el-sources-32b

I've never used this OS by the way, but I got interested by this thread and googled around a bit
One of the zips actually gave that same source code.
meynaf is offline  
Old 20 August 2018, 17:20   #45
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,366
Quote:
Originally Posted by meynaf View Post
. ipl=0 is exact same as ipl=1 (not an annoyance but an oddity)
Maybe you mean ipl=6 is the same as ipl=7?
This anyway is unavoidable if you want a NMI...

However what makes me puzzled is the lack of tst (ofs,pc) when btst #x,(ofs,pc)* exists.
Ok ok in 020+ is implemented but WHY not in 000?


*Some assembler wrongly complain that is only 020+..
ross is offline  
Old 20 August 2018, 17:22   #46
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,201
Quote:
Originally Posted by meynaf View Post
You call that complete ? Have a look at the API list ! They don't even have support for basic memory allocation !

Sure they do, using system call 64:
http://www.menuetos.net/syscall.txt
Leffmann is offline  
Old 20 August 2018, 17:32   #47
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Quote:
Originally Posted by ross View Post
Maybe you mean ipl=6 is the same as ipl=7?
This anyway is unavoidable if you want a NMI...
Doh, perhaps i don't even remember exactly.
But isn't it that ipl=6 allows both 6 & 7 (anything >=6) but ipl=7 only 7, while ipl=0 allows >=0 but there is no level 0 so it's the same as 1 ?


Quote:
Originally Posted by ross View Post
However what makes me puzzled is the lack of tst (ofs,pc) when btst #x,(ofs,pc)* exists.
Ok ok in 020+ is implemented but WHY not in 000?

*Some assembler wrongly complain that is only 020+..
Perhaps because TST was implemented with similar hardware as CLR, NOT, NEG, NEGX, which were all read-modify-write (including, wrongly, CLR).
meynaf is offline  
Old 20 August 2018, 17:32   #48
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Quote:
Originally Posted by Leffmann View Post
Sure they do, using system call 64:
http://www.menuetos.net/syscall.txt
In the interview they say they don't have proper malloc.

EDIT: they say exactly :
Quote:
Currently Menuet applications have a continuous memory area, which you can resize with a system call.
Not what i'd call memory allocation, even basic...

Last edited by meynaf; 20 August 2018 at 17:38.
meynaf is offline  
Old 20 August 2018, 17:46   #49
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,201
That interview is 9 years old. Basic memory allocation means just extending the heap, but convenient memory allocation in malloc-style is also available (even if it's typically not the job of the kernel), it says so right there in the link I posted, under system call 64.
Leffmann is offline  
Old 20 August 2018, 17:47   #50
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,366
Quote:
Originally Posted by meynaf View Post
Doh, perhaps i don't even remember exactly.
But isn't it that ipl=6 allows both 6 & 7 (anything >=6) but ipl=7 only 7, while ipl=0 allows >=0 but there is no level 0 so it's the same as 1 ?
ipl=6 doesn't allow any maskable IRQ (same as 7)
ipl=0 allows >0, so every IRQ
ipl=1 allows >1, and so on

Quote:
Perhaps because TST was implemented with similar hardware as CLR, NOT, NEG, NEGX, which were all read-modify-write (including, wrongly, CLR).
Well, I can understand for the listed instructions, that are all with modification of the destination, but not for a read only operation!
(if same die part is used for this operation is sure a bad implementation, but ehi, is a 1979 project with limited transistor usable )

I must always remember not to use it

ross is offline  
Old 20 August 2018, 17:53   #51
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Quote:
Originally Posted by Leffmann View Post
That interview is 9 years old. Basic memory allocation means just extending the heap, but convenient memory allocation in malloc-style is also available (even if it's typically not the job of the kernel), it says so right there in the link I posted, under system call 64.
Ok, you have the point.

Nevertheless if you look at that list, you'll see it is some vm, maybe some framework, but certainly not a fully featured operating system.
That thing is like building a tower in a swamp. A marvel of engineering maybe, but still pointless and can only end up as touristic curiosity.

So what ? Some folks managed to do something and suddenly it becomes easy ?
These people have struggled 10-15 years to do something that remotely looks like an OS.

Now please stop that menuetOS nonsense. What they did does not mean in any manner that x86 is practical to use for this, just that it is possible. And it is possible for just every available cpu.
meynaf is offline  
Old 20 August 2018, 18:04   #52
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Quote:
Originally Posted by ross View Post
ipl=6 doesn't allow any maskable IRQ (same as 7)
ipl=0 allows >0, so every IRQ
ipl=1 allows >1, and so on
In my memory it did put level+1 in ipl field when an interrupt occurs. I guess it's been too long i haven't fiddled with these...

But then ipl=7 would mask level 7 but they just prevented it ?


Quote:
Originally Posted by ross View Post
Well, I can understand for the listed instructions, that are all with modification of the destination, but not for a read only operation!
(if same die part is used for this operation is sure a bad implementation, but ehi, is a 1979 project with limited transistor usable )

I must always remember not to use it

The CLR bug is a strong hint in that direction anyway. Damned electronicians always take shortcuts where they shouldn't

Another reason for me to prefer coding on 68030
meynaf is offline  
Old 20 August 2018, 18:58   #53
ross
Sum, ergo Cogito

ross's Avatar
 
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 48
Posts: 1,366
Quote:
Originally Posted by meynaf View Post
In my memory it did put level+1 in ipl field when an interrupt occurs. I guess it's been too long i haven't fiddled with these...
IRQ -> ipl field = level

Quote:
But then ipl=7 would mask level 7 but they just prevented it ?
Yes, this is the little oddity
But admissible to allow an NMI to always be accepted.
ross is offline  
Old 20 August 2018, 23:47   #54
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
My only issue with the 68000 CPU is that the bus takes between a week and a month to fetch a memory address. Other CPUs had better bus interfaces (even 8 bit ones!!) so they could get better instruction throughput. The Amiga had reasonably fast ram but the 68000 never took advantage of that.

Things got a little better on the 68030.. it only takes a day to get data delivered from RAM and they finally fixed it on the 040.

Although the ARM has its flaws its memory throughput never fails to impress me.

EDIT: And the 6800 SYNC bus interface was a giant WTF. You have to wait until xmas for your data.
plasmab is offline  
Old 21 August 2018, 00:40   #55
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 644
68000 memory access is actually no slower than the 8086. For block moving, it’s actually quite a bit faster. For reference, the 68000 also outclasses the 6502, 8080, Z80 and 6800 for memory speed

The ARM is indeed much faster, but well, what do you expect of a CPU design that’s 8 years newer (it’s from the same year as the 68030).
roondar is offline  
Old 21 August 2018, 01:41   #56
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
68k details

Quote:
Originally Posted by roondar View Post
68000 memory access is actually no slower than the 8086. For block moving, it’s actually quite a bit faster. For reference, the 68000 also outclasses the 6502, 8080, Z80 and 6800 for memory speed

The ARM is indeed much faster, but well, what do you expect of a CPU design that’s 8 years newer (it’s from the same year as the 68030).


Not the 6502 it doesn’t.

BBC B gets 0.5 mips at 2mhz. Same as the Amiga at 8mhz
plasmab is offline  
Old 21 August 2018, 02:26   #57
roondar
Registered User

 
Join Date: Jul 2015
Location: The Netherlands
Posts: 644
Quote:
Originally Posted by plasmab View Post
Not the 6502 it doesn’t.
It most certainly does. A 1MHz 6502 manages to copy about 2000b/50Hz frame, which is about 4000b/frame for a 2Mhz one. A 7Mhz 68000, as used in the Amiga, manages closer to 17000b/frame.

Which means the 68000 has faster memory access than the 6502 - even if the 68000 where to be slowed down to 2MHz, it would still win for memory access speed.
Quote:
BBC B gets 0.5 mips at 2mhz. Same as the Amiga at 8mhz
1) the 6502 uses 8 bits per instruction, the 0.5 mips figure for the 68000 is based on it running 32 bit instructions (it’s about 1 mips for 16 bit instructions).

2) even if it where true, the 68000 instruction set and 6502 instruction set are extremely different. Merely comparing intstructions per second for two architectures that are so different is just not going to work.

I’ll give just two examples:
1) a simple move.w d(an),d0 - a very common operation - takes just 12 cycles on 68000. The equivalent 6502 code (something like ldx #2; lda address,x; tay; inx; lda address,x) will take 14 cycles. Which is slower even clock for clock, let alone if it actually ran at 2Mhz vs 7Mhz.

2) divu or mulu are so much faster than even table based 6502 versions it’s not even funny.

There are plenty more examples here. Generally, the more you want your code to actually do, the bigger the 68000 advantage becomes.
roondar is offline  
Old 21 August 2018, 09:38   #58
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
Yes. I give you it’s an apples and oranges performance comparison. Point remains... a plain 68000 takes 4 cycles to access the bus and the 6502 takes 2 base cycles. Plus the BBC makes its ram work on both edges of the clock.

Sure the 6502 only accesses 8 bits at a time and yes the 68000 is a better CPU. But it’s ram performance is awful.
plasmab is offline  
Old 21 August 2018, 09:53   #59
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 45
Posts: 3,344
Quote:
Originally Posted by roondar View Post
There are plenty more examples here. Generally, the more you want your code to actually do, the bigger the 68000 advantage becomes.

And yet we still see people comparing very small code snippets. This pisses me off.


Quote:
Originally Posted by plasmab View Post
Sure the 6502 only accesses 8 bits at a time and yes the 68000 is a better CPU. But it’s ram performance is awful.
This is true, but what to expect ? 6502 is designed to work on a setup where memory is faster than the cpu, and not the 68000. I'm no hardware designer, but isn't it obvious memory performance get worse as clock rate gets higher ?

Compare that to todays architectures experiencing a cache miss, and you'll see who's bad in terms of ram performance
meynaf is offline  
Old 21 August 2018, 10:06   #60
plasmab
Banned
plasmab's Avatar
 
Join Date: Sep 2016
Location: UK
Posts: 2,917
68k details

Quote:
Originally Posted by meynaf View Post


And yet we still see people comparing very small code snippets. This pisses me off.







This is true, but what to expect ? 6502 is designed to work on a setup where memory is faster than the cpu, and not the 68000. I'm no hardware designer, but isn't it obvious memory performance get worse as clock rate gets higher ?
I can put both chips on 10ns static RAM. The 6502 theorically maxes the RAM at 200MHz. The 68000 would need to go to 400Mhz... the first ARM maxes out at 100Mhz... same for the 040.

Quote:



Compare that to todays architectures experiencing a cache miss, and you'll see who's bad in terms of ram performance

Rubbish! A 68000 needs 4x 140ns per ram access. The first access on SDRAM/DDRx is 70-80ns and it’s 10-30ns to pull each sequential memory location thereafter depending on the memory type.

You don’t know what you are talking about. I’ve built controllers for SDRAM and DDR.

Plus a modem CPU pulls 128 bits per access.
plasmab is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
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 12:22.


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