Click Here
home features news forums classifieds faqs links search
5830 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
17 crawler(s) on-line.
 17 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 sTix:  26 mins ago
 nikosidis:  28 mins ago
 Dragoon:  30 mins ago
 pvanni:  39 mins ago
 edponpon:  46 mins ago
 Jairah:  1 hr 21 mins ago
 gryfon:  1 hr 39 mins ago
 Musashi5150:  1 hr 41 mins ago
 noXLar:  1 hr 56 mins ago
 rajsons:  2 hrs 15 mins ago

/  Forum Index
   /  Amiga General Chat
      /  AmiWest 2019 clarifications
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 | 7 Next Page )
PosterThread
billt 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 1:25:14
#61 ]
Elite Member
Joined: 24-Oct-2003
Posts: 3156
From: Maryland, USA

@Birbo

Quote:
Can you explain how the work together with Hyperion is organized? Or is the developement of the Exec totally seperate from the rest of developement of Amiga OS 4.1?


Watch the Amiwest videos... It's in there.

_________________
All glory to the Hypnotoad!

 Status: Offline
Profile     Report this post  
ne_one 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 2:42:19
#62 ]
Cult Member
Joined: 13-Jun-2005
Posts: 885
From: Unknown

@coldacid

Quote:
Honestly, it might be easier and more worthwhile to take the Dragonfly BSD kernel, hack UAE into it for legacy apps, and build a whole new OS on top of that similar to Apple building OSX on top of Mach+NeXT, than to try and hack memory safety into Exec. Legacy and current AmigaOS pretty much requires memory insecurity to function at all, that bird has flown.


I'm sure there will be screams of blasphemy but I too can't possibly imagine investing limited resources into retrofitting things like SMP into a rickety foundation.

The academic exercise may prove to be interesting and it may help justify purchases of the A5000 and A1222 but it's really a solution looking for a problem.

There are countless other areas that need to be addressed and investing in the past is going to prevent the platform from moving forward.

 Status: Offline
Profile     Report this post  
bison 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 4:14:45
#63 ]
Super Member
Joined: 18-Dec-2007
Posts: 1667
From: N-Space

@coldacid

Quote:
Honestly, it might be easier and more worthwhile to take the Dragonfly BSD kernel, hack UAE into it for legacy apps, and build a whole new OS on top of that similar to Apple building OSX on top of Mach+NeXT, than to try and hack memory safety into Exec. Legacy and current AmigaOS pretty much requires memory insecurity to function at all, that bird has flown.

I think there's a lot of merit to that idea, but... that's a subject for a another thread.

_________________
"Unix is supposed to fix that." -- Jay Miner

 Status: Offline
Profile     Report this post  
umisef 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 6:17:15
#64 ]
Super Member
Joined: 19-Jun-2005
Posts: 1676
From: Melbourne, Australia

@tonyw
Quote:

tonyw wrote:
@thread

It is not true to say that there are macros for Forbid(), Permit(), Disable() and Enable(), expanding to inline code. These are all Exec calls and must go through the Exec's library vectors to be actioned.

This was true in the 68k days and is still true in PPC-land.


That's lovely in theory. Unfortunately, the NDK3.9, as (still) available from H&P has the following assembler macro for DISABLE:


DISABLE MACRO ; [scratchReg],[NOFETCH] or have ExecBase in A6.
IFC '\1','' ;Case 1: Assume A6=ExecBase
MOVE.W #$04000,_intena ;(NOT IF_SETCLR)+IF_INTEN
ADDQ.B #1,IDNestCnt(A6)
MEXIT
ENDC
(...)

and this one for FORBID:

FORBID MACRO ; [scratchReg],[NOFETCH] or ExecBase in A6!
IFC '\1','' ;Case 1: Assume A6=ExecBase
ADDQ.B #1,TDNestCnt(A6)
MEXIT
ENDC
(...)

And at the top of that file

** $VER: ables.i 39.0 (15.10.1991)


So for the last 28 years, at least, the 68k NDK has included officially sanctioned macros that (a) simply manipulate Exec's private state memory, and (b) actually hit the chipset directly.


 Status: Offline
Profile     Report this post  
Georg 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 8:48:31
#65 ]
Regular Member
Joined: 14-May-2003
Posts: 442
From: Unknown

Stuff like Forbid/Permit/Disable/Enable even as macros are no problem at all if you start one AOS instance per (big) app. Think about it in similar way as starting two UAEs. In one you run "Final Writer". In the other you run "Directory Opus". They are completely isolated, can do forbid/permit/macro/whatever. Can crash themselves or the(ir) OS. It will not affect the program in the other UAE. And when they crash, they would max. crash their OS instance (UAE) but not the other. And OS instances can run on different cores.

Comparision with UAE is only to show isolation similarities with such approach. It does not mean approach would inherit slowness or startup slowness or resource hungryness of UAE.

An AOS (instance) by itself does not take up basically any resources or cpu time. If you have a single big app (no other stuff like Workbench) running in AOS waiting for user input on a slow PC (if AOS was x86 native and AOS app was ported as native x86 app) then it would be maybe eating 0.01 % cpu time of the single core it is running on. Because there's not much else then timer ticks going through input.device/input handler/intuition happening. You could probably have 1000s of AOS instances running at the same time and still nowhere near reach 100 % cpu load.

With something like this you would have memory protection between (big) apps, resource tracking, multiple core (not full/real SMP) for free with no speed loss, without change of APIS (forbid/permit, access to OS structures: no problem).

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 10:02:15
#66 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11417
From: Norway

@Georg

Quote:
stuff like Forbid/Permit/Disable/Enable even as macros are no problem at all if you start one AOS instance per (big) app.


I think the programs that used this macros are already broken, you can't break anything that is already broken , it clear we need a new NDK3.1.4 / NDK3.2 that includes fixes for stupid stuff like this. So that people who is working on stuff on mc680x0 can compile safely there programs without having to worry about things like this.

I come more and more to the conclusion that sandboxing might be the best decision for AmigaOS.
1. You most do it anyway when going 64bit.
2. It allows you remove linked lists and stupid stuff like that from the host kernel.
3. You can schedule task in background, without making changes to the core OS.
4. You move critical stuff out of harm's way, (console, disk, keyboard, rs232), some thing like debug console might be useful think action replay iii.

Last edited by NutsAboutAmiga on 02-Nov-2019 at 11:43 AM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 10:16 AM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 10:04 AM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 10:03 AM.

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

 Status: Offline
Profile     Report this post  
tonyw 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 10:38:37
#67 ]
Elite Member
Joined: 8-Mar-2003
Posts: 3200
From: Sydney (of course)

@umisef

Thanks, Bernie. I wasn't aware of the assembler macros. I simply looked up the library function vectors.



_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

 Status: Offline
Profile     Report this post  
lylehaze 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 11:28:31
#68 ]
Super Member
Joined: 1-Sep-2004
Posts: 1128
From: North Florida - Big Bend area.

@mr2

I am still present, and still coding.
My "real life" has put additional demands on my time, so I'm not as productive as I once was.

I'm not working on RadeonAudio at the moment. I don't know if someone else has picked it up.

I am still working in Audio drivers, and I am still looking forward to leaving drivers behind and getting back to Score.

When any of this reaches "complete" is not at all predictable.

Thanks,
Lyle

_________________
question=(2b||!(2b))

 Status: Offline
Profile     Report this post  
salass00 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 12:17:40
#69 ]
Elite Member
Joined: 31-Oct-2003
Posts: 2702
From: Finland

Having done some programming in 680x0 assembler for Amiga computers, I never understood why anyone would want to use the assembler macros for shared library calls when it's so simple to just do:

move.l SysBase(pc),a6
jsr _LVOForbid(a6)

If anything, using them just leads to more inefficient code as the library base register is needlessly reloaded from memory.

 Status: Offline
Profile     Report this post  
Hypex 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 14:13:42
#70 ]
Elite Member
Joined: 6-May-2007
Posts: 10027
From: Greensborough, Australia

@Snorg

Quote:
That's why I asked - a poor attempt at humour, "Is this thing on?" - that is to ask the same thing.


And likewise. "Have you tried turning it off and on again?"

Quote:
Consider the purpose of Forbid(), Permit(), Enable(), and Disable(). Essentially, they make a set of operations atomic - i.e. to execute as a 'transaction'. Ideally, such transactions are initiated and completed by the OS in order to ensure correct behaviour should the underlying hardware or software change.


Yes that was the underlying purpose but in their case they took it to an extreme. One disables multitasking and the other disables interrupts. The first will freeze the system interface but the other will completely freeze the system. Allowing simple user programs such power just looks like a bad idea. That's a really trustworthy OS.

If data needs atomic access that's what semaphores are for. I use them in my own programs. But, internally they forbid multitasking.

Quote:
Although it was more efficient to use macros instead of OS calls, the unfortunate result is the situation we have: *for any* macros *that* expand to inline(d) machine (68K) instructions instead of OS calls, *there is thus* no way to 'intercept' and properly handle these transactions in, for instance, multi-processing environments


I would say there is. All they do, at their core, is increase a byte counter in ExecBase. The macros would do the same as Exec does internally. So, I really didn't see why there needed to be ASM macros. Just to save a JSR call before temporarily freezing the system.

Though I liked the idea of each 68K application being an own task, I agree ExecBase needs to be isolated away from 68K. Now is the time. In fact, OS4 software should have no need to touch ExecBase either, and they shouldn't need too. But, a legacy ExecBase created for 68K would help here, that is only used for classic programs.

Last edited by Hypex on 02-Nov-2019 at 02:18 PM.

 Status: Offline
Profile     Report this post  
Snorg 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 14:30:42
#71 ]
Regular Member
Joined: 1-Feb-2018
Posts: 117
From: Unknown

@Georg

"Stuff like Forbid/Permit/Disable/Enable even as macros are no problem at all if you start one AOS instance per (big) app. "

Or one per core, but I suspect there are practical advantages in delegating legacy to one core.

Anyway, I'd like to say thanks to all who posted their insights here. I wish I were optimistic, but I'll move on now - as my wife says, opening your mouth just gets you in trouble.

 Status: Offline
Profile     Report this post  
mr2 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 15:51:36
#72 ]
Cult Member
Joined: 3-Feb-2004
Posts: 657
From: Poland

@lylehaze

Ah, ok. Thanks for the info. I hope you can finish the boring staff and have fun with Score again.

_________________
Sam440ep-flex 800MHz 1GB RAM R9250 128MB SB Live!

 Status: Offline
Profile     Report this post  
Jose 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 17:34:44
#73 ]
Cult Member
Joined: 10-Mar-2003
Posts: 934
From: Unknown

@megol
"As I wrote the problem is that Forbid() must immediately halt all other processors and doing it with standard hardware is AFAIK impossible as only the processor accessing the protected area will trap. Perhaps one could handle that with the trapped processor interrupting all other processors making them wait on a semaphore. Overheads would be great though: at least MMU trap + Inter processor Interrupt broadcast + semaphore overheads."

But aren't the cores accessing the protected areas the only ones that need to be trapped ? And each core has it's own MMU that can trap it, so I missing why you say there would need to be MMU trap + Inter processor interrupt broadcast + semaphore overheads. I know nothing about MMUs other than what they generally do but I think the PPC MMU would be the same. There would probably be some overhead when launching processes due to setting up the other MMUs for the traps.

_________________

JosÚ

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 18:07:23
#74 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11417
From: Norway

@Jose

No it can't be just trapped, beside when should you release control of that data?

Also when working with trap handlers you have the same problem, if try change trap handler and put your code there, how can be sure that trap handler is not over written, by different program before you can trigger the trap.

Also I'm skeptical about the suggestion of using ques, becomes if let's say insert some code from program A, into list or que, there is chance that program A, as quit'ed before code is executed, the nice code also gone by the time que is executed.

Also when you dream up alternatives to MUTEX or SHAMPORES or SPINLOCKS and so on you will have issue when porting over software, you can't use the MUTEX locks because this what is the standard, on all operating systems.

Last edited by NutsAboutAmiga on 02-Nov-2019 at 06:13 PM.
Last edited by NutsAboutAmiga on 02-Nov-2019 at 06:11 PM.

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

 Status: Offline
Profile     Report this post  
ssolie 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 19:47:43
#75 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2747
From: Alberta, Canada

@mr2
Quote:
Quote:
I prefer to stay lock step with Hyperion on releases.

Any idea about a payment for such releases? I would gladly pay if they bring some new features.

I try to stay out of the money side of things myself so I don't know what the decision is on that front.

_________________
ExecSG Team Lead

 Status: Offline
Profile     Report this post  
ssolie 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 19:50:41
#76 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2747
From: Alberta, Canada

@Gregor
Quote:
What is the latest U-Boot version for X5000/20?...

U-Boot has been a concern of mine for a long time. Now that we have ExecSG under control, I think reaching back into the firmware is a logical step. With that in mind, I want to see if we can arrange something with A-EON in regards to firmware so that a) everybody is on the same version and b) we can update it as needed. It only makes sense.

Sorry I don't have any specifics. I'm more concerned about who controls it at this point.

_________________
ExecSG Team Lead

 Status: Offline
Profile     Report this post  
ssolie 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 22:12:36
#77 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2747
From: Alberta, Canada

@Petah
Quote:
Percentage-wise, how much work on the drivers and other software exclusive to the A1222 Tabor is completed and how much remains to be done?

I don't see much point in doing percentages. Programmers always tell you they are 90% complete. What I do know is we have an ISO now so full system testing has resumed. In short, I don't see product shipping until next year at this point.

Quote:
Are any major hurdles concerning the remaining work on the A1222 Tabor software expected to show up, or will the final stretch be more about smooth sailing and less about obscure, hard-to-find bugs?

There are certainly a couple of show stoppers left to fix for sure. It won't be smooth sailing and never is.

_________________
ExecSG Team Lead

 Status: Offline
Profile     Report this post  
ssolie 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 22:16:12
#78 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2747
From: Alberta, Canada

@Lou
Quote:
What are the odds of back-porting to 68k?
What are the odds of the port everyone and their mother wants (ARM)?

I can certainly say everything is on the table again.

But let's focus on the immediate future which means X5000 and A1222. I believe there was a promise to have AmigaOS 4.2 on the X1000 as well unless Hyperion has changed its mind. So we already have plenty to do.

_________________
ExecSG Team Lead

 Status: Offline
Profile     Report this post  
ssolie 
Re: AmiWest 2019 clarifications
Posted on 2-Nov-2019 22:19:19
#79 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2747
From: Alberta, Canada

@kamelito
Quote:
How did Microsoft managed to be very compatible with all previous versions of Windows (even before win95) and be able to have true SMP/memory protection and so on, why it is not possible on Amiga? This mean that technical solutions exist right?

Money. It also helped to have a world wide monopoly.

_________________
ExecSG Team Lead

 Status: Offline
Profile     Report this post  
ssolie 
Re: AmiWest 2019 clarifications
Posted on 3-Nov-2019 1:36:57
#80 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2747
From: Alberta, Canada

@Fl@sh
Quote:
I'd like to know if new exec will have standard SMP just like windows/linux os or a simpler AMP design, where extra cpus could be managed as async coprocessors.

In order to retrain backwards compatibility some sort of hybrid solution is most likely.

_________________
ExecSG Team Lead

 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