Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
31 crawler(s) on-line.
 41 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 Karlos:  15 mins ago
 AmigaPapst:  34 mins ago
 SOFISTISOFTWARE:  37 mins ago
 Marcian:  40 mins ago
 Musashi5150:  41 mins ago
 kolla:  49 mins ago
 Hammer:  1 hr 9 mins ago
 cdimauro:  2 hrs 3 mins ago
 bhabbott:  2 hrs 21 mins ago
 matthey:  2 hrs 24 mins ago

/  Forum Index
   /  General Technology (No Console Threads)
      /  Applied Micro moving away from PowerPC
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 Next Page )
PosterThread
megol 
Re: Applied Micro moving away from PowerPC
Posted on 18-Oct-2014 19:56:23
#101 ]
Regular Member
Joined: 17-Mar-2008
Posts: 355
From: Unknown

@Samurai_Crow
Quote:

Samurai_Crow wrote:
@cdimauro

Quote:

cdimauro wrote:
@Samurai_Crow

Last but not least, MMUs are implemented and quite a standard feature from about 20-25 years now: why you don't want them? They represent a good compromise from the hardware implementation point of view, albeit with a big granularity. They, also, make the address translation a very fast operation, since the calculations are made into a pipeline stage (so, well hidden in the pipeline). Address translation is a good thing, because it let you implement virtual memory, and fast loaders (don't need to relocate code and data).


The reason I hate MMUs is that we had a perfectly fast and responsive OS 25 years ago. The modern implementations are not much if any faster despite having 10 times faster processors.


You hate MMUs? At best I'd say you are severely indoctrinated in a false religion and at worst ready for the looney bin.

Hint: using virtual addressing actually is used to accelerate things in modern operating systems.

Quote:

You want to eliminate load times? Use position-independent code! Relative addressing is really useful in a flat memory model. Using virtualized address space? Not so much.


You can have a single addressing space design (that is the technical term) with MMU support. There have been many systems like it.

Quote:

Being able to monitor for writes or protect from writes is only 2 bits per page. That much I will sacrifice for an MMU. No more. Memory protection can be implemented in a flat memory model more easily than in a virtualized address space anyway.


So how large are your pages? How are they managed? How much overhead do you need for that management?

--
Let's do a thought experiment: linear packed array (4 pages/byte). 4GiB memory. 4kiB pages.

Array size=4GiB/4kiB=1Mi pages. Pack that into the array -> 1Mi/4=256kiB.

Nice right?

We don't want to have the array stored in DRAM - it would be to slow. And we don't want to store it in a dedicated SRAM at the processor - if we have the SRAM available we'd want to use it for standard caching instead.
So we have to cache the array instead. Standard optimization technique.

Each read of the array will fetch data for cache line width*4 pages. A standard line size nowadays are 64 bytes so 256 pages will be fetched for each read.

The dedicated cache have to be pretty small and pretty fast (while it would be possible to make it almost as large as the L1 data cache again - if one have the resources it would be wiser to spend it on the data cache instead).
Let's assume a 8kiB L1 data cache, taken from actual 68k processor implementations in FPGA. We want to be able to cover the whole data cache contents so we need 8kiB/4kiB (page size) = 2 entries. However that is just the minimum, a wiser choice would be ~16 entries. 16 entries are reasonable and still pretty fast. Each entry will be a cacheline entry in size.

16 entries x 256 pages = 4096 pages or 16MiB!

So this solution would provide protection for up to 16MiB of data which should be enough _iff_ the data locality reduces the cache capacity misses. If one accesses 16 addresses in a row with a stride of 4096*256 there will be a cache miss party of course.
--
But is this any better than a MMU that supports translation too?
Instead of 16 entries we could have 64 or more entries in the MMU cache (called TLB or ATB for some) as each entry can be much smaller while still being efficient.
The management structure can be tree shaped or using an inverted page structure instead of a linear array. This means that instead of drilling down to a certain page before knowing if one can access it one can do a lookup that tells if the page below will need to be checked.

64 entries x 4096 bytes per page = 256kiB mapped. Still good, will probably cover the L1 cache _and_ a large L2 cache. Less sensitive to capacity misses than the above scheme due to the larger amount of entries.

Quote:

Address translations that cost pipeline length will make branches less responsive by introducing bubbles. I like short responsive pipelines and MMU pipelining makes them neither short nor responsive.


LOL!
MMU lookup are done for free in any reasonable processor. No extra pipeline stages. Virtually Indexed Physically Tagged caches are the standard. Amiga OS could use Virtually Indexed Virtually Tagged caches too but the advantages are very few.

Don't want overheads? Don't touch pages you doesn't own -> virtually no overheads.

Quote:

If you find out managed code doesn't work for you? You recompile the code not to use it and use a faster OS! How do you get a short pipeline out of a CPU with a long pipeline? IT IS IMPOSSIBLE!


But as pointed out above you are not even wrong - you are very wrong.

 Status: Offline
Profile     Report this post  
itix 
Re: Applied Micro moving away from PowerPC
Posted on 19-Oct-2014 2:04:07
#102 ]
Elite Member
Joined: 22-Dec-2004
Posts: 3398
From: Freedom world

@cdimauro

Quote:

Strange. I never bet a coin on it. Do you know why it's needed?


For virtual addresses and memory protection. In MorphOS there is Quark kernel and ABox (Amiga application layer) runs there under this kernel. There is no direct interface to use MMU and Exec does not use MMU, but ABox and therefore anything running there (Exec and so on) are under MMU control.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Applied Micro moving away from PowerPC
Posted on 19-Oct-2014 8:05:01
#103 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3619
From: Germany

@megol

Quote:

megol wrote:

LOL!
MMU lookup are done for free in any reasonable processor. No extra pipeline stages. Virtually Indexed Physically Tagged caches are the standard. Amiga OS could use Virtually Indexed Virtually Tagged caches too but the advantages are very few.

Please, can you explain how it's possible?. My though was that one pipeline stage is needed to do the address translation.

I mean, after the AGU has calculated the virtual address (in the proper pipeline stage), before you can send the physical address to the load/store unit, it has to be translated of course.

I know that it's possible to do some other useful work in parallel, while in the same pipeline stage, so this way the address translation can be masked, but this depends on the particular implementation, so maybe you cannot always do other stuff as well.

@itix

Quote:

itix wrote:
@cdimauro

Quote:

Strange. I never bet a coin on it. Do you know why it's needed?


For virtual addresses and memory protection. In MorphOS there is Quark kernel and ABox (Amiga application layer) runs there under this kernel. There is no direct interface to use MMU and Exec does not use MMU, but ABox and therefore anything running there (Exec and so on) are under MMU control.

Interesting. But is it possible to disable the MMU with Quark? Since the only box which is used currently is the ABox, which doesn't require it.

 Status: Offline
Profile     Report this post  
itix 
Re: Applied Micro moving away from PowerPC
Posted on 19-Oct-2014 12:33:19
#104 ]
Elite Member
Joined: 22-Dec-2004
Posts: 3398
From: Freedom world

@cdimauro

Quote:

Interesting. But is it possible to disable the MMU with Quark? Since the only box which is used currently is the ABox, which doesn't require it.


I dont kno but I doubt it. ABox is not only "box" running there, few other servers run parallel to ABox.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

 Status: Offline
Profile     Report this post  
Hypex 
Re: Applied Micro moving away from PowerPC
Posted on 19-Oct-2014 14:24:01
#105 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@cdimauro

Quote:
But that way you're wasting a precious address register only for this.


Shouldn't matter. Using a register to store the global and local data pointer is common in code. And on 68K there are a few registers to make use of.

Quote:
What kind of "proper testing" do you mean?


I mean testing every function of the program, keys, menus, general operation. Common conditions such as OS resource allocation fails like memory, files or windows should be generated and tested. Rare ones like unusual file names or spaces tested and anything other known rare conditions. Really, every internal function should be tested along with conditions that make sure all parts of routines are called and not just common parts. Without dedicated tools on the Amiga this would be hard. But ARexx support can help if it can be programmed to call every function.

Quote:
Use macros.


I can use macros in a hex editor to read littel endian files?

Quote:
That's my opinion.


Looking at a few x86 soruce files it seems common place to reverse short and long words when comparing with a direct number.

Quote:
I'm an aficionado of Visual Studio


Well on OS4 we seem to miss out on tools where we can take a third party source, add the files and get it to compile cleanly right then and there.

 Status: Offline
Profile     Report this post  
megol 
Re: Applied Micro moving away from PowerPC
Posted on 19-Oct-2014 16:55:15
#106 ]
Regular Member
Joined: 17-Mar-2008
Posts: 355
From: Unknown

@cdimauro

http://cseweb.ucsd.edu/classes/fa10/cse240a/pdf/08/CSE240A-MBT-L18-VirtualMemory.ppt.pdf

The only reason to use an extra pipeline stage is if one wants a cache with a huge amount of ways - or fully associative.

@Hypex

Quote:

I can use macros in a hex editor to read littel endian files?


What? If you can't read them yourself nothing will help you.

Quote:
Looking at a few x86 soruce files it seems common place to reverse short and long words when comparing with a direct number.


What?!? This is so wrong that it's funny!
But please go ahead and show an example.

Last edited by megol on 19-Oct-2014 at 04:59 PM.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Applied Micro moving away from PowerPC
Posted on 20-Oct-2014 14:03:54
#107 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@megol

Quote:
What? If you can't read them yourself nothing will help you.


I can't read them if all the words are backwards, I have to spend time decoding what I'm looking at. It's hard to tell the difference between a word and a byte as they are all mixed together. A big endian file OTOH is easier to look at as it's easier to seperate words and long words.

Even if I could read Hebrew it wouldn't help as the words are all backwards instead of the entire line.

Quote:
What?!? This is so wrong that it's funny!


I'm glad you think so. LOL.

But here is an example from the Stargus project code. This section scans a for an "MPQ" header.


UInt32 mpq_header[2] = { 0x1a51504d, 0x00000020 };

UInt32 detected = 0;
UInt32 tmp;

while (fread(&tmp, sizeof(UInt32), 1, fpMpq)) {
if (mpq_header[0] == tmp) {
fread(&tmp, sizeof(UInt32), 1, fpMpq);
if (mpq_header[1] == tmp) {
detected = 1;
break;
}
}


Now you will see that it reads in the file long words at a time. Then compares it with an ID that is backwards. Now why can't it compare it exactly how it appears on disk? I would have expected the long word disk read to reverse the bytes as they are read from disk and then the comparison to reverse the bytes in the header as the header long word is read into a register for comparing. thus yielding the same result. But no, the data has to be reversed in the header. So, it looks like two backwards don't make a forwards.

The header appears as below on disk:
{ 0x4d50511a, 0x20000000 };

With big endian you just use the exact value you are looking for. In the little endian code above you must reverse the data. This is confusing! The programmer should be able to specify exactly what he is looking for as it appears externally, in this case a file. But in this code he cannot. Perhaps it is the use of fread() that confuses the issue.

 Status: Offline
Profile     Report this post  
minator 
Re: Applied Micro moving away from PowerPC
Posted on 20-Oct-2014 19:33:36
#108 ]
Cult Member
Joined: 23-Mar-2004
Posts: 989
From: Cambridge

@Samurai_Crow

Quote:
The reason I hate MMUs is that we had a perfectly fast and responsive OS 25 years ago. The modern implementations are not much if any faster despite having 10 times faster processors.


The perceived speed of the OS has pretty much nothing to do with the presence or absence of an MMU. It's all down to the design of the OS.

When I first used BeOS back in 1998 it was highly responsive. It had full memory protection and it was running on a 120MHz Pentium. Windows was an absolute dog on the exact same hardware.

_________________
Whyzzat?

 Status: Offline
Profile     Report this post  
broadblues 
Re: Applied Micro moving away from PowerPC
Posted on 20-Oct-2014 20:36:44
#109 ]
Amiga Developer Team
Joined: 20-Jul-2004
Posts: 4446
From: Portsmouth England

@Hypex
Quote:

But here is an example from the Stargus project code. This section scans a for an "MPQ" header.



The code you quote deals with the fact that the data on disk is BigEndian and the Processor is expected to LittleEndian, one of them has to be reversed unless you you do a byte by byte check.





_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

 Status: Offline
Profile     Report this post  
megol 
Re: Applied Micro moving away from PowerPC
Posted on 21-Oct-2014 11:57:24
#110 ]
Regular Member
Joined: 17-Mar-2008
Posts: 355
From: Unknown

@broadblues

Exactly. Just as a big endian processor needs to swap little endian data - like when playing RIFF type files (e.g. Wav).

But the idea that this is a common thing is 100% wrong. Like it or not the current standard is little endian - x86 and most ARM systems run in little endian mode.

 Status: Offline
Profile     Report this post  
megol 
Re: Applied Micro moving away from PowerPC
Posted on 21-Oct-2014 12:18:37
#111 ]
Regular Member
Joined: 17-Mar-2008
Posts: 355
From: Unknown

@Hypex

Quote:

Hypex wrote:
@megol

Quote:
What? If you can't read them yourself nothing will help you.


I can't read them if all the words are backwards, I have to spend time decoding what I'm looking at. It's hard to tell the difference between a word and a byte as they are all mixed together. A big endian file OTOH is easier to look at as it's easier to seperate words and long words.

Even if I could read Hebrew it wouldn't help as the words are all backwards instead of the entire line.


But why do you find this such a big problem when reading hex files in itself is just an undefined bunch of bytes? Even when reading big endian data you have to know the extent of each data field to parse it.

For me reading big endian or little endian hex data is just the same, a PITA but not really hard. Little endian is easier to parse for some things, big endian for others.

 Status: Offline
Profile     Report this post  
michalsc 
Re: Applied Micro moving away from PowerPC
Posted on 21-Oct-2014 12:33:18
#112 ]
AROS Core Developer
Joined: 14-Jun-2005
Posts: 377
From: Germany

@cdimauro

Quote:
Quote:
I dont know if AROS standalone version uses MMU but it can run Linnux hosted where MMU is of course used by the host OS.

AROS/68K not, for sure, as wawa already reported. I don't think that it changes with other architectures, but I don't have such kind of knowledge now.


I don't remember current situation with i386 native AROS, but x86_64 as well as all native PPC and ARM targets do use MMU.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Applied Micro moving away from PowerPC
Posted on 25-Oct-2014 7:11:25
#113 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3619
From: Germany

@Hypex

Quote:

Hypex wrote:
@cdimauro

Quote:
But that way you're wasting a precious address register only for this.


Shouldn't matter. Using a register to store the global and local data pointer is common in code. And on 68K there are a few registers to make use of.

For locals you can use, and you normally use, the stack pointer, unless you have to deal with stack frames (inner functions).
Globals don't require a register, because they can be accessed with absolute addressing.
The problem with 68K is that it has few address registers, so saving one can make the difference on performance. I had problems with address registers in the past, working with that ISA, and much less with data registers.
Quote:
Quote:
What kind of "proper testing" do you mean?


I mean testing every function of the program, keys, menus, general operation. Common conditions such as OS resource allocation fails like memory, files or windows should be generated and tested. Rare ones like unusual file names or spaces tested and anything other known rare conditions. Really, every internal function should be tested along with conditions that make sure all parts of routines are called and not just common parts. Without dedicated tools on the Amiga this would be hard. But ARexx support can help if it can be programmed to call every function.

That's what developers already try to do, but unfortunately bugs are still there.

To get what you want you need to resort to formal code verification, which is utterly expensive, and cannot be used for complex software. In fact, it's used only on some medical devices (e.g. pacemakers) or for the controlling software of the core in a nuclear central, for example.

Have you always released totally bug-free software?
Quote:
Quote:
Use macros.


I can use macros in a hex editor to read littel endian files?

It's trivial. You can take a look at the macros whic I used on WPython, my Python virtual machine.

Anyway, I saw the other messages, and I agree with megol: there's nothing the prevents you to write portable code which takes care of the endianess of the data.
Quote:
Quote:
I'm an aficionado of Visual Studio


Well on OS4 we seem to miss out on tools where we can take a third party source, add the files and get it to compile cleanly right then and there.

You can install plug-ins on Visual Studio, so you can do whatever you want. I use it for developing Python code, for example, and it works like a charm.

@megol

Quote:

megol wrote:
@cdimauro

http://cseweb.ucsd.edu/classes/fa10/cse240a/pdf/08/CSE240A-MBT-L18-VirtualMemory.ppt.pdf

The only reason to use an extra pipeline stage is if one wants a cache with a huge amount of ways - or fully associative.

Oops. I totally forgot the caches here. You're right and there's no need for extra pipeline stages to implement address translation.

So, Samurai, the pipeline is not affected by the MMU implementation. Do you still have the same opinion?

@michalsc

Quote:

michalsc wrote:
@cdimauro

Quote:
Quote:
I dont know if AROS standalone version uses MMU but it can run Linnux hosted where MMU is of course used by the host OS.

AROS/68K not, for sure, as wawa already reported. I don't think that it changes with other architectures, but I don't have such kind of knowledge now.


I don't remember current situation with i386 native AROS, but x86_64 as well as all native PPC and ARM targets do use MMU.

Thanks for the information. Do you know the reason why it's used?

 Status: Offline
Profile     Report this post  
Hypex 
Re: Applied Micro moving away from PowerPC
Posted on 26-Oct-2014 14:35:12
#114 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@broadblues

Actually, the data on disk is in little endian format. Just the "MPQ" ID is in order, which I would have expected from a text ID.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Applied Micro moving away from PowerPC
Posted on 26-Oct-2014 14:38:58
#115 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@megol

If I know the basic layout of a file then it can look confisng or out of place in little endian. OTOH with big endian it's easier to identify 16-bit and 32-bit words as they tend to stand out if they aren't too large. It helps more if the layout isn't known.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Applied Micro moving away from PowerPC
Posted on 27-Oct-2014 14:23:01
#116 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@cdimauro

Quote:
Globals don't require a register, because they can be accessed with absolute addressing.


Usually with a compiler switch for sensitive applications like library or interrupt when globals are needed at any time. But, most C code used A4 for globals and linked in A5 to the stack for locals. So register indirrect addressing was used quite a bit and said to be faster trhan absolute addressing as well as being more efficient on space.

It's also common on PPC where it cannot do absolute addressing like 68K can.

Quote:
The problem with 68K is that it has few address registers,


I never saw this as a problem before. Usually it was x86 that got low register count problems. The 68K was always thought to have a good amount of registers that could be put to good use in things I read.

Quote:
Have you always released totally bug-free software?


Can't say I have. An old propgram I wrote won't work on my A4000 for some reaosn. Doesn't crash but cannot create GUI, don't know why. With CIAgent I found it had a rare condition where it would crash. Within about two hours of finding out (IIRC), I had found the bug, fixed it and uploaded an update. I couldn't stand the thought of someone finding a crash before I did. Especially knowing if I had buggy code online.

Quote:
Anyway, I saw the other messages, and I agree with megol: there's nothing the prevents you to write portable code which takes care of the endianess of the data.


Then it should be done! But more likely, the code works fine on x86, so it must be fine attitude.

Quote:
You can install plug-ins on Visual Studio,


And this can help us to compile software on OS4? Can it be used to cross compile on a PC and take out all the hard work that would be needed to compile directly on OS4?

Last edited by Hypex on 28-Oct-2014 at 01:30 PM.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Applied Micro moving away from PowerPC
Posted on 27-Oct-2014 21:20:59
#117 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3619
From: Germany

Hypex

Quote:

Hypex wrote:
@cdimauro

Quote:
Globals don't require a register, because they can be accessed with absolute addressing.


Usually with a compiler switch for sensitive applications like libary or interrupt when globals are needed at any time.

Library and interrupts have known places where to put data (pointer to user data).
Quote:
But, most C code used A4 for globals and linked in A5 to the stack for locals.

Sorry, when I talk about 68K, I usually think in terms of assembly language.

Yes, for C code, compilers use A4 and A5. I don't know if they generate some kind of statistics about the registers usage, and can reuse such registers in some pieces of code. At least A5 I think can be reused often, for "not complicated" functions.
Quote:
So register indirrect addressing was used quite a bit and said to be faster trhan absolute addressing as wel las being more efficient on space.

But it costs a register, A4. Anyway, it's not evident that the register indirect address is faster than the absolute one. A processor with proper caches and pipeline can hide the cost of longer instructions with (long) absolute addressing, and in general the impact of the 2 more bytes depends on the micro-architecture and the type of code which is executed.

Last but not least, in a virtual address space the globals can be located on the lowest addresses, so a 16-bit (short) absolute address can be used instead of a 32-bit one, obtaining the same space advantage of the register indirect addressing using the A4 register. MMUs rulez.
Quote:
It's also common on PPC where it cannot do absolute adressing like 68K can.

PPCs have 32 registers: having one for globals doesn't hurt the performance.
Quote:
Quote:
The problem with 68K is that it has few address registers,


I never saw this as a problem before.

I had it in the past, especially with my 80186 emulator (entirely written in 68020+ assembly).
Quote:
Usually it was x86 that got low register count problems.

Exactly. But with x64 the situation is greatly improved, since there are 16 (mostly) general purpose registers, plus a PC-relative address mode.
Quote:
The 68K was always thought to have a good amount of registers that could be put to good use in things I read.

Yes, but they are split in data and address registers, and the latter aren't all available, unfortunately.
Quote:
Quote:
Have you always released totally bug-free software?


Can't say I have. An old propgram I wrote won't work on my A4000 for some reaosn. Doesn't crash but cannot create GUI, don't know why. With CIAgent I found it had a rare condition where it would crash. Within about two hours of finding out (IIRC), I had found the bug, fixed it and uploaded an update. I couldn't stand the thought of someone finding a crash before I did. Especially knowing if I had buggy code online.

So, have you encountered only one bug in you coder life? I think it's a unique, absolutely uncommon, case.
Quote:
Quote:
Anyway, I saw the other messages, and I agree with megol: there's nothing the prevents you to write portable code which takes care of the endianess of the data.


Then it should be done! But more likely, the code works fine on x86, so it mus tbe fine attitude.

I think that coders that manipulate data with such a low-level detail should know that endianess problems, and address them with the usual techniques.

However, that itsn't all that it's needed to handle such cases. Reading an int, for example, doesn't guarantee that you're reading 4 bytes.
Quote:
Quote:
You can install plug-ins on Visual Studio,


And this can help us to compile software on OS4? Can it be used to cross compile on a PC and take out all the hard work that would be needed to compile directly on OS4?

Absolutely. But you need a plug-in for this. Writing plug-ins for Visual Studio is simple enough, and there's MingW or Cygwin that can be used to cross compile (using GCC).

However Visual Studio also allows you to create and use the so called "Debug engines", which let you control every aspect of the IDE in debug mode. It means that, for example, you can very comfortably debug your OS4 application (or for other o.s.es / machines) inside Visual Studio, exactly like you do with the regular debug engines (to debug C++, C#, VB.NET, etc.). It requires some time to write it, but you aren't forced to implement all the Debug Engine interface, so you can leave some features as unimplemented, and do them in future.

 Status: Offline
Profile     Report this post  
Samurai_Crow 
Re: Applied Micro moving away from PowerPC
Posted on 28-Oct-2014 5:45:54
#118 ]
Elite Member
Joined: 18-Jan-2003
Posts: 2320
From: Minnesota, USA

@minator

Quote:

minator wrote:
@Samurai_Crow

Quote:
The reason I hate MMUs is that we had a perfectly fast and responsive OS 25 years ago. The modern implementations are not much if any faster despite having 10 times faster processors.


The perceived speed of the OS has pretty much nothing to do with the presence or absence of an MMU. It's all down to the design of the OS.

When I first used BeOS back in 1998 it was highly responsive. It had full memory protection and it was running on a 120MHz Pentium. Windows was an absolute dog on the exact same hardware.


I like Haiku too. (Haiku is to BeOS what AROS is to AmigaOS.) It just has less software than the Amiga 68k. It just seems like a waste of RAM to use it up on page-table buffers when you have a simple OS that uses a flat memory model.

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Applied Micro moving away from PowerPC
Posted on 28-Oct-2014 6:38:53
#119 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3619
From: Germany

@Samurai_Crow, are you seriously complaining about memory usage on 2014? This sub-notebook which I'm using now has 4GB of ram. How much memory is needed for using an MMU? The minimum is 4K (one PDE, Page Directory Entry) + 4K (one PTE, Page Table Entry) = 8KB on x86 and many other architectures, and your application can address up to 1024 * 4K = 4MB of memory without requiring other memory for the page tables.

Filling the PDE requires 1024 * 4KB = again 4MB in total, but now you are able to address the full 4GB address space. Just for example, there are processors nowadays that can store more than 4MB on their L3 cache!

So, what are we talking about? Your battle against (paged / normal / common) MMUs looks irrational...

 Status: Offline
Profile     Report this post  
Hypex 
Re: Applied Micro moving away from PowerPC
Posted on 28-Oct-2014 14:15:52
#120 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@cdimauro

Quote:
Library and interrupts have known places where to put data (pointer to user data).


Yes but it isn't alwasy used.

Quote:
Sorry, when I talk about 68K, I usually think in terms of assembly language.


Okay, I see. Well, going back to my own code, when I wrote DOS commands in ASM I got into the habit of storing DOSBase in D7. I could move it there to test if it opened and then move on with my code as it was already stored in place.

Quote:
But it costs a register, A4


Yes, just one. However, the 68K design also costs a register, A7, for the stack. I never got that, it looked out of place and bad design to use address register for stack pointer.

Quote:
16-bit (short) absolute address can be used instead of a 32-bit one,


Never thought about this for 68K. It would need MMU to use it so rare optimisation. However, one tihng I forgot until now, is PC relative addressing. As long as the address is reachable from the instruction this was also a faster way to access data, or so I read. I think this was useful for ASM, as you didn't need to manage it through anotrher register.

Quote:
PPCs have 32 registers: having one for globals doesn't hurt the performance.


And yet it is only double of 68K. Of course they are not specific but GPRs. Register agaiin used for stack, but looking at code, it looks like stack is emulated throught GPR and not done directly with CPU like 68K did with A7 or SP as they also called it.

Quote:
So, have you encountered only one bug in you coder life?


I doubt it. Bugs can have many forms. I consider a crash to be a show stopper.

Perhaps the ones I hate the most are in code I have ported. Since it isn't code I wrote and it can be hard to know why it is crashing. Also it gets annoying getting bug reports about code you haven't written in the first place. You want to move it upstream but the people are asking you.

Quote:
Reading an int, for example, doesn't guarantee that you're reading 4 bytes.


It used to be 2 bytes. And why we have macros like int32 these days.

Quote:
Absolutely. But you need a plug-in for this.


That sounds good then. Almost putting OS4 compiling to shame.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle