@Trev

Quote:

everyone seems to be ignoring the fact that Bernd is a developer, discussing his difficulties with OS4's APIs. Though sometimes confusing to read, his views are still valid, as are everyone else's.

No he's not, he's only showing his disdain to Hyperion and the work done on AmigaOS 4, and this is done by throwing attacks on AOS4's devs capabilities, generaly presenting false informations or partial sentences/words extracted from their context as verified facts just to harm Hyperion/AOS4.

I have nothing against criticism neither do I with people having other preference than me anyway what I can bear on the other hand is manipulation, FUD spreading and hypocrisy.

Oh and last x->y() is still a valid construct to call a function as this is the basis for any OOP programming if this is not dealt correctly by the compiler/optimizer than we will be in deep troubles using C++...

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@bernd_afa

Quote:

Have you test DeletePool too ?

I just tested DeletePool(NULL) for you and it also doesn't give a GrimReaper...

Quote:

ah ok, this is same done in bsdsocket.library on 68k, so no reason to write Ixec->

Me and several others have already told you that you don't have to write Interface->FunctionName(), if it really bothers you, you can use the old-style calling convention and simply write FunctionName() without the interface name.

But let me give you another example: what happens if you have two libraries which both happen to use the same function name, and you need to use them both in your program? The OS4 interface system solves that problem as well.

Quote:

So what come out at the end is near same.

Sure, in the end it all boils down to a JSR/bl, but that doesn't make any of the advantages of the OS4 system that me and others mentioned go away.

@itix

What I was explaining to bernd is what becomes possible with the interface system, I'm not saying that these pointers/structures are protected with the MMU right now (I didn't check to be honest), I'm saying the library interface system allows such protection, and makes it easier and cleaner to implement next-gen interfaces with an API which allows full memory protection, while keeping the old interfaces as well.

Re: conflicting libraries, most operating systems have the same issue--Windows with its "DLL hell" and Unix with its multiple lib paths and serioulsy long chains of symbolic links.

I don't yet have OS4 (the more I discuss it here, though, the more I want to check it out), but I've read over a bit of the public SDK and interface documentation, i.e. os4_libraries_devices.pdf. I think I understand why the designers went this route--it needed to facilitate a migration from OS3, after all--but I see of lot work being done to solve problems that have already been solved by other languages, e.g. C++, Objective-C, and other object models, e.g. COM. I'm not knocking the solution, though. It makes sense to solve the problems in an Amiga-like way. Some time might have been saved, perhaps, by borrowing from established standards and practices.

One little comment: It sounds like it's not possible to call a native library from emulated code. You'd think the design would have included a standard 68k to native proxy interface, perhaps simply by providing an appropriate jump table before the library base. Am I interpreting the documentation correctly?

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: One little comment: It sounds like it's not possible to call a native library from emulated code. You'd think the design would have included a standard 68k to native proxy interface, perhaps simply by providing an appropriate jump table before the library base. Am I interpreting the documentation correctly?

If that were the case then no emulated app could run, since all apps require calling some OS library calls. The 68k jump-table is there, although it is possible to create a library without one. Generally speaking it's not a good idea to omit the 68k jump table, unless you're absolutely certain that there will never be a 68k version of that library.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Trev

Quote:

Trev wrote: I don't yet have OS4 (the more I discuss it here, though, the more I want to check it out), but I've read over a bit of the public SDK and interface documentation, i.e. os4_libraries_devices.pdf. I think I understand why the designers went this route--it needed to facilitate a migration from OS3, after all--but I see of lot work being done to solve problems that have already been solved by other languages, e.g. C++, Objective-C, and other object models, e.g. COM. I'm not knocking the solution, though. It makes sense to solve the problems in an Amiga-like way. Some time might have been saved, perhaps, by borrowing from established standards and practices.

You should have heard the ruckus here when they announced that they had added the ability to load and use shared-objects.

Whilst it is true that these things have been solved by other languages, taking advantage of those solutions would basically lock development of OS4 to those languages, and any language whose compilers can be hacked to work the same way. The OS4 solution means that C developers can also use it. This is no different from BOOPSI providing a flexible and language independent object orientated programming framework.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Trev

And, to complete Hans´ answer, for the purpose of calling native PPC libraries, there is some "glue code" resp. emulator´s library function call convention. It is provided in the form of the main interface of a native library "converted" to a standard 68k jump table (as seen from the 68k application´s POV). This is your proxy interface.

Regards

@Hans

Quote:

You should have heard the ruckus here when they announced that they had added the ability to load and use shared-objects.

Yes, I'd wondered about that.

I've thought about using BOOPSI for things other than GUI widgets, but if I'm going to write something that needs to be portable, it's probably not a good idea....

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev


Quote:

I don't yet have OS4 (the more I discuss it here, though, the more I want to check it out),

Yes get a Sam440flex is a nice computer.

Quote:

You'd think the design would have included a standard 68k to native proxy interface,

JMP table point to "stub functions", the "stub functions" handles the 68k to native proxy.

JMP Table (list of old 68k functions)
=> Stub_OpenLibrary() read 68k registers
=>=> OpenLibrary()
=> Stub_OpenLibrary() set 68k return values

if you need to execute 68k code from naive powerpc code you can run Emulate() function.

I believe AmigaOS4 uses illegal instruction exceptions and memory exceptions to detect if code is native or not.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Trev

Quote:

One little comment: It sounds like it's not possible to call a native library from emulated code. You'd think the design would have included a standard 68k to native proxy interface, perhaps simply by providing an appropriate jump table before the library base. Am I interpreting the documentation correctly?

I'm pretty sure you can have emulated 68k programs call native libraries, for instance you can use a native mpega.library with 68k software without problems.

@Trev

And I will also add that the reverse is also possible : PPC code calling 68k libraries (provided there is a small glue code that will provide PPC interface on the JMP table, which can be generated using only .FD or .SFD descriptionof the library). That was the path taken to incrementally develop AOS4 : the PPC kernel was calling 68k libraries running emulated and those libraries were replaced by PPC native version one after the other...

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@Hans
> doesn't develop for OS 4,

seem you havent read it, but here again more clear, i am the only guy on OS4 that get a graphical source level debugger working on OS4.and that was some years ago

@Cobra
>Me and several others have already told you that you don't have to write Interface->FunctionName(), if it really bothers you, you can use the old-style calling convention >and simply write FunctionName() without the interface name.

yes of course, but this thread is a speculation how realistic it is, if Hyperion can realize a good working Memory Protect AOS.

for new OS that use GCC, and this OS should reack more than 1000 users, it is common behavior that this OS come in GCC main core and it is possible to use newest compiler.

But OS4 is not add in GCC
if you really mean, that programers with lots programming knowledge learn a OS that is not offical add in gcc source tree and the only compiler is GCC, i think you dream

also if Hyperion is not able to add their OS in gcc compiler source to build easy GCC, how realistic is it then, that Hyperion really get a memprotect OS working, if they are not able to do the OS Standards

Last edited by bernd_afa on 17-Apr-2009 at 01:09 PM.
Last edited by bernd_afa on 17-Apr-2009 at 12:56 PM.

@bernd_afa

I think there's a big language barrier between you and the people you're talking to. For instance:

Quote:

yes of course, but this task is a speculation how realistic it is, if Hyperion can realize a good working Memory Protect AOS.

I do not see how that is a reply to:

Quote:

Me and several others have already told you that you don't have to write Interface->FunctionName(), if it really bothers you, you can use the old-style calling convention and simply write FunctionName() without the interface name.

How realistic what is? You can already do what he told you, there's no speculation there.

_________________

@Zardoz

i want tell in the example of the library system which is one of the very new design features of OS4, that Hyperion seem not able to do API that is acceptable to many, because the OS4 interface is not add in GCC.

The thread theme is this.

>What if Hyperion is now actually working on this completely new API?

And i write what i think and bring indices so other can see wy i this think.
I think also its better when devs are able to do memprotect system, do them self and help on Anubis instead of waiting for Hyperion do that.

Full Memorprotect and Parametercheck, cost also more speed, so there is also faster OS4 HW need.

Last edited by bernd_afa on 17-Apr-2009 at 01:21 PM.

Quote:

I think also its better when devs are able to do memprotect system, do them self and help on Anubis instead of waiting for Hyperion do that.

So, you have another favourite now, fine. You´re changing your mind quite often... a few days before your favourite was AfA, before that it was AROS, before that it was emulated 68k...

Just stop talking here and do yourself something to help Anubis, please. People here know the pros and cons of OS4.x much better than you, so it is pointless to hijack this thread for your personal agenda.

Btw., topic was not "memory protection enabled API and what Bernd Roesch thinks about it using weird assumptions", it was "Hyperion Entertainment ... embarks on its most ambitious project to date". This states nothing about what exactly this project may be. You´re free to speculate about what this project may be, but you will stay off topic as long as you try to convince other people that the work of Hyperion and many others is "disorganized", which is your own very personal opinion and not backed up by any claim you made so far.

Regards

@bernd_afa

I wasn't saying that Hyperion are going to do a complete redesign of the OS and APIs now, what I was saying is that the framework is there, which will allow that to happen. It's just that it needs huge amounts of work to do, and I don't see Hyperion having so much money right now to undertake such a task.

Regarding GCC, I really don't understand your problem, the OS4 SDK does have an up to date GCC included with support for the OS4 interfaces. There's also another C compiler called vbcc available, which supports the OS4 interface conventions as well, as well as the PortablE E compiler, in fact even the FreePascal compiler is available for OS4 with support for the OS4 interfaces. So there's really no problem in my opinion as far as compilers and OS4 go.

@whose

>This states nothing about what exactly this project may be.

read the intro thread.there was question if Hyperion work on a complete new API.

"""
Some people have been discussing the pros/cons of a totally new API for OS4. What if Hyperion is now actually working on this completely new API?
"""

>Just stop talking here and do yourself something to help Anubis, please.

I am not able to develop a memprotect API that is so security save as windows or Linux and i dont let people think i can do that.

but lets see what happen with OS4 in 4 years if i speculate realistic or not that Hyperion get no secure working memory protect AOS

@cobra

>the OS4 SDK does have an up to date GCC included with support for the OS4 >interfaces.

the gcc of OS4 is a old 4.2 series.currently is 4.3.3 and 4.4.0.this have changed register allocater(to IRA) and give better optimition and more features-

So lets see if for OS4 come a 4.3 or 4.4 compiler out and the OS4 syntax can easy add here

look how the gcc4 of OS4 is updatet, there are new files merged in old files
http://adtools.svn.sourceforge.net/viewvc/adtools/trunk/gcc/

this really look not amazing, espeical that there are millions of formalar possible and not all formular can test if a backport and remerge of code really work 100% ok

So i and most developers i think prefer a OS support in Main gcc source if they want spend much time to coding for the OS.

so is the OS4 call convention with asd-> really need and OS4 compilers can so not easy build from gcc main source ?

>what I was saying is that the framework is there, which will allow that to happen.

yes here i agree, but it is very very few and this was easy to do.very very much need done.

Last edited by bernd_afa on 17-Apr-2009 at 02:27 PM.
Last edited by bernd_afa on 17-Apr-2009 at 02:26 PM.
Last edited by bernd_afa on 17-Apr-2009 at 02:24 PM.
Last edited by bernd_afa on 17-Apr-2009 at 02:20 PM.

@bernd_afa

Getting the GCC team to accept and include a new target isn't exactly easy, and would require months of work and correspondence. I bet the OS4 devs have better things to do.

@bernd_afa

It's a common mistake to think that the latest version of GCC is always the best to use. There have been a lot of issues which were caused by quite a lot of different GCC versions. When I worked at QNX, there was a guy there whose job was specifically to maintain the QNX port of GCC, and he did a lot of work to test which was the latest stable, and trouble-free GCC compiler, and there was always an official version (which was never the latest one), which was considered to be stable and well tested, and that was the one which everyone used for development. There's a similar process going on when the OS4 SDK is prepared. The SDK contains a version of GCC, which was thoroughly tested by many developers and reported to be OK and to produce stable and well working code. What matters for developers is that they don't waste precious time hunting bugs which turn out to be bugs in the compiler.

@COBRA

>It's a common mistake to think that the latest version of GCC is always the best to >use.

but if a program fail to work, there should be easy possible to test if a new compiler work better, or produce faster code.i see also on 68k that sometimes 3.4 is faster as 4.3(pngcrush).but most time 4.3 with IRA register allocater is faster.and this can be 30% or more.

gcc compiler have all the time bugs in, some were fixed in newer release, its also possible that new bugs add that in older release are not.

because compilers are very complex you cant say a compiler is 100% bug free, especial when optimizng.so it is also a good idea when port a program use the compiler they use, when problems come