WarpUP vs ppc.library test!
Johan Rönnblom
WarpUP vs ppc.library test!
This is a challenge to everyone who has a PowerUP card, to determine
which of these systems that is really faster.
Instead of using an existing demo, which may be handcrafted to suit
one of the systems better, everyone is invited to program these very
basic 'applications' as well as he/she can.
Of course, these tests are not very comprehensive. So, if you have
ideas for better tests, please send them to me.
Please do not send them to this thread, if you want to discuss
appropriate tests then start a new thread!
If I get response to these tests, I will post some more tests that
have been suggested. But if everyone starts posting them, then soon
the PowerUP programmers contributing will all be coding completely
different tests, and we will have no use of them..
Please note that tests should try to avoid to specify *how* a program
should do anything, and concentrate on the result. Programmers should
be free to do it the best way they can!
I personally don't have a board, so I do I don't know how many times
loops should be repeated to get times that are easy to compare.
Instead, I say that each of the loops should be repeated 10^n times,
where n is the lowest integer that make the entire routine take more
than 10 seconds to execute.
---
Test 1:
Allocate 1000000 bytes of memory. Fill it with $c001c0de. Free the
memory. Repeat 10^n times and return.
This *should* not show any difference between the systems, but one
could never be too sure, and it will give us an idea of the memory
performance of the PowerUPs too. :)
---
Test 2:
*1* Set the value A to 987654321.
*2* You must have the value A in a 68k-program now.
*3* Set B=A
*4* Divide B by 22233 somehow, but only keep the integers.
Multiply with 22232. Add 222.
*5* Repeat from *4* 200000 times.
*5* Using the 68k, print B on the screen somehow.
*6* Subtract 1 from A.
*7* Repeat from *2* 10^n times.
---
Test 3:
Calculate the square root of all integers from 1 to 100000 using the
PPC fsqrt instruction.
Multiply by 1000000 and convert them to a 32-bit integer using the
fctiw instruction. Fill a 400000 bytes large buffer with these,
_using the 68k_.
You can do it any way you like, either calculate all of them and send
them, or one at a time, or calculate and send groups. You are allowed
to allocate several buffers, the only requirement is that the results
are finally written to memory using the 68k. You may not read and
immediately write them to the same buffer however.
Repeat this 10^n times.
---
When you have done some or all of the tests, send a mail to
jrb...@mtek.chalmers.se containing the following information:
1. Whether you have been using ppc.library only, powerpc.library V7,
or WarpUP. Or some other solution. ;)
2. What tools were used. (E.g StormC, GnuC, etc.)
3. The number of times (10^n) that each loop was repeated.
4. The total running time (should be between 10 and 99 seconds..)
5. Your system details. Of particular interest is what type of SIMMs
you are using, for example 60 or 70 ns.
Also attach an archive with the executable(s) and full sourcecode.
*DONT* post results here immediately, I will post them as soon as I
get replies using both systems. This way they will be easy to
compare.
Also, I will put the executables and sources so that everyone can
download them and check that the reported timings are correct.
Hopefully I will get lots of replies..
/Johan Rönnblom, Team Amiga
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Anders Melchiorsen
Johan Rönnblom wrote:
>
> WarpUP vs ppc.library test!
Will people ever stop doing benchmarks and instead spend their time
doing something useful? It really is of little interest how quick a
certain product is at doing absolutely nothing.
> Hopefully I will get lots of replies..
Sure, the time spend arguing over benchmarks is just as wasted as the
time spent actually doing them.
--
-And
Kenneth
Johan Rönnblom wrote:
>WarpUP vs ppc.library test!
>2. What tools were used. (E.g StormC, GnuC, etc.)
Just a little note: it's said that StormC is optimized for WarpUp so using
StormC wouldn't give correct result (if the statement is true).
Regards,
---
/"`` Kenny mailto:ke...@bgnett.no http://www.bgnett.no/~kenny/
\/ software developer finger me for details
---
Keith Blakemore-Noble
Anders Melchiorsen <a...@kampsax.dtu.dk> writes:
>Johan Rönnblom wrote:
>>
>> WarpUP vs ppc.library test!
>
>doing something useful? It really is of little interest how quick a
>certain product is at doing absolutely nothing.
OK then.
Perhaps YOU can tell us which system is the faster one so that
we can all ensure that we all develop for the faster one then?
TTFN,
Keith
Hans Guijt
Anders Melchiorsen (a...@kampsax.dtu.dk) wrote:
>Will people ever stop doing benchmarks and instead spend their time
>doing something useful? It really is of little interest how quick a
>certain product is at doing absolutely nothing.
Actually this _is_ useful. Phase5 and H&P are currently fighting it out on
their websites, and until we have a clear winner we need to determine by
ourselves what product we will use for software development. Knowing the
performance can be helpful.
Hans
Patrick Kursawe
Hi,
>Anders Melchiorsen <a...@kampsax.dtu.dk> writes:
>Perhaps YOU can tell us which system is the faster one so that
>we can all ensure that we all develop for the faster one then?
How do you think could that be tested? Storm C(++) is just for WarpUp, the
GNU-stuff is just for the original PowerUp-software AFAIK. Or do you know a
compiler which exists for both systems?
No matter how such a test would end, I think it is nearly as dumb as the
construction of the tower of Babel to develop software for A HACK.
Correct me if I am wrong (or for any other reason...)
- H&P did NOT develop the hardware.
- p5 did NOT document it or promise it will not change
- the H&P "solution" is compatible with NOTHING but H&P products whereas
- the p5 software uses ELF which is quite common for other PPC systems,
making cross-development easier and will definitely exist on future PPC
boards by p5 (if there will be any...)
Even IF the H&P software is a bit faster I see absolutely no reason why anyone
should use it instead of what the developers of the hardware ship with it.
Just for the case you are curious: I am NOT paid by p5. And I did not yet
order a PPC board.
My personal opinion: WarpUp is FUTILE and DUMB. Try to convince me of the
opposite :-)
Bye, Patrick
--------------------------------------------------------------------------
Patrick Kursawe Patrick...@ruhr-uni-bochum.de
Hohenzollernstr. 69 http://www.anachem.ruhr-uni-bochum.de/patrick
45128 Essen Keep smiling! :-)
Amiga makes it... well, not possible, but definitely more fun.
Keith Blakemore-Noble
"Patrick Kursawe" <Patrick...@ruhr-uni-bochum.de> writes:
>Correct me if I am wrong (or for any other reason...)
>
>- H&P did NOT develop the hardware.
True.
>- p5 did NOT document it or promise it will not change
P5 have documented (afaik) a HAL, but H&P have hacked to try to
access teh hardware directly - a VERY dangerous thing to do!
>- the H&P "solution" is compatible with NOTHING but H&P products whereas
Exactly. It also, I am lead to understand, disables the P5 library, so
that you cannot run H&P-based apps with the existing P5 system - a VERY
bad move on teh part of H&P.
>- the p5 software uses ELF which is quite common for other PPC systems,
> making cross-development easier and will definitely exist on future PPC
> boards by p5 (if there will be any...)
True.
Also, the H&P system is only compatible with StormC (from, suprisingly, H&P)
whereas the P5 one is already compatible with GNU C (supplied with the PPC cards)
and there is a PPC version of SAS/C due soon which is also for use with the P5
system.
Looks to me that H&P are trying to muscle in on P5's PPC system, and trying to
force out competition for their compiler.
>Just for the case you are curious: I am NOT paid by p5. And I did not yet
>order a PPC board.
:) Me too. My board is sitting here just waiting for my A4000 to come back :(
>My personal opinion: WarpUp is FUTILE and DUMB. Try to convince me of the
>opposite :-)
I would have to agree with you there, I guess.
On reflection, I would probably now tend to agree that making comparisons
between the speed of the two systems is a bit pointless, until H&P can
provide a version of, say, GNU which will compile for thie system. Until
then, you are right - we can't really make any meaningful comparisons., and
shoudl really stiuck to the P5 solution which IS more robust anyway, by definition.
TTFN,
Keith
Hans Guijt
Keith Blakemore-Noble (Am...@computer.org) wrote:
Hi Keith, we meet again!
I read your message and am somewhat concerned about your negative statements
wrt. Haage&Partner. I think that as long as we don't know the relative
merits of both products, it is too early to judge them. I _do_ know that
Phase5 totally overreacted to H&P's announcement. What they should have done
is call H&P (on the phone - they actually live quite near to each other and
know each other quite well) and ask just what is going on. Then after
talking things over (and only then) should they have come out with a joint
statement, preferably, or separate statements, if necessary. Bringing their
grievances out into the open didn't help anyone - Phase5, H&P, or the Amiga.
Anyway, there is something that seems to have escaped most people, and which
is quite relevant to this discussion: the H&P offering actually consists of
two parts.
The first part is a library which can run on top of either the Phase5
software or the H&P kernel (the second part). Programs compiled by StormC
require this library, but since the library coexists peacefully with the
Phase5 software (ie. it doesn't disable their kernel) the 'H&P are trying to
monopolize the market' argument is simply not true. This part is called
WarpUP.
The second part is an exec-style kernel which can replace the Phase5 kernel,
and is very much superior to it, according to H&P. This kernel replaces the
Phase5 kernel, but since the Phase5 kernel is monolithic this also means it
replaces the rest of the Phase5 software. This part is called WarpOS.
So users get a choice: run the H&P kernel if you can use the speed and only
need programs that use the H&P library, or run the Phase5 kernel if you need
a mix of H&P-style and Phase5 programs.
According to tests the message handling in Phase5s kernel is so slow that it
has problems with processing mouse movements. WarpOS does not suffer from
such processing lag. I think that counts as a reason to use WarpOS.
>>- H&P did NOT develop the hardware.
>True.
But not quite relevant. Phase5 writes, on their website, that they support
the development of alternative OSes for the PowerUp. Apparently this doesn't
include WarpOS.
>>- the p5 software uses ELF which is quite common for other PPC systems,
>> making cross-development easier and will definitely exist on future PPC
>> boards by p5 (if there will be any...)
Unfortunately the ELF format does not allow Amiga-style libraries and
requires programs to be loaded at absolute addresses. I don't know about you
but I do not want to loose libraries just so we can use Windows-based
compilers.
On the other hand, the EXECUTABLE format used by H&P is the standard Amiga
hunkformat, WITHOUT any extensions. The 'proprietary' extensions H&P defined
were only to the Amiga OBJECT format. This means that when you compile a
program with StormC you must also use the StormC linker - nothing more.
Endusers will never know the difference, whether they are running WarpOS or
Phase5s kernel. There is simply no incompatibility between StormC and
PowerUp.
>>My personal opinion: WarpUp is FUTILE and DUMB. Try to convince me of the
>>opposite :-)
Hope this helps. H&P are simply not as evil as they are made out to be on
the Phase5 website, and I thoroughly regret that the PowerUp initiative has
met with this kind of misfortune. Some simple communication between H&P and
Phase5 could have spared us a lot of grief.
I have a feeling that Phase5 is using this opportunity to get us all to use
some as yet unspecified UNIX clone. This may be great for them (it
facilitates development for their A/Box which runs Linux), but it may not be
so great for us (Amiga users in general).
I like AmigaOS the way it is - with shared libraries, relocatable
executables, etc., and I don't want any UNIX clone to replace it. If my
suspicions are correct WarpOS may be the one thing that can save AmigaOS
from the clutches of Linux.
As a sidenote, has anyone noticed that WarpOS has been endorsed by Amiga
In[c|t]. on their respective websites?
Hans
Kenneth
Hans Guijt wrote:
>>>- H&P did NOT develop the hardware.
>>True.
>But not quite relevant. Phase5 writes, on their website, that they support
>the development of alternative OSes for the PowerUp. Apparently this doesn't
>include WarpOS.
But WarpUP isn't a OS _for_ the PowerUp kernal - it's a replacement which
doesn't support PowerUP kernal at all AFAIU. I believe Phase 5 meant that
they support alternative OS'es which _support_ PowerUP kernals (not only the
PowerUP card). Correct me if I'm wrong here.. Anyway:
I feel H&P did a big mistake not doing a principle communicating with Phase
5 on this. Personally I think I'll support Phase 5 on this, not only because
of the hard work they have put into this project and their loyalty to the
Amiga community, but since we need a standarisation (on the Amiga) for the
hardware by people who knows the hardware. Maybe Phase 5's standard isn't
the best, but even the longest way starts with a first step.
If H&P had tried to establish a dialog some of H&P's ideas could just maybe
be implemented in PowerUP, but trying to steal the whole cake isn't pretty
popular - that's what Bill You-know-who's company do all the time.
Tor-Einar Jarnbjo
On 06-Okt-97 00:07:22, Hans Guijt wrote in comp.sys.amiga.programmer:
>Unfortunately the ELF format does not allow Amiga-style libraries and
>requires programs to be loaded at absolute addresses. I don't know about you
>but I do not want to loose libraries just so we can use Windows-based
>compilers.
Do you seriously claim, that Linux (which also uses ELF-binaries) load
its programs to absolute addresses? IMHO, the functionality of shared
objects under Unix, is also quite similar to the Amiga libraries.
Tor-Einar
Ben Hutchings
In article <949.7218T...@inter.nl.net>,
Hans Guijt <hgu...@inter.nl.net> wrote:
>Ben Hutchings (worc...@sable.ox.ac.uk) wrote:
>>This is bad because it means there is no possibility to add support for
>>virtual memory and so on by using an extra hunk to mark programs that it
>>is safe to load-on-demand.
>
>So despite the fact that ELF
>
>* cannot support Amiga-style libraries
>* cannot support CHIP or FAST hunks
>* cannot support relocatable sections
>
>you still prefer it?
No.
>>It is hardly a secret that Phase 5 wants people to move on to A\Box, and
>>that so far they have only committed to a UNIX-like OS for that.
>
>Correct. But must we accept that as the future of the Amiga?
No.
--
Ben Hutchings, compsci&mathmo | ICOAmiga http://www.lapcopaintball.com/icoa/
email/finger m95...@ecs.ox.ac.uk | homepage http://users.ox.ac.uk/~worc0223/
Never put off till tomorrow what you can avoid all together.
Kenneth
Emmanuel Henn wrote:
[...]
>And for me, as a user, I don`t care what solution is in the software
>I buy (for example TORNADO3D by H&P), as long as it pushes my
>(future) PowerUP-card to the max :-)
Ok, well, I am first interrested to hear reports from people using the
PowerUp cards. If they work well, how fast, stable etc. Then I hope there
will be a solution on the WarpUP vs PowerUP "situation". In the mean time I
will joy my Amiga as-is :)
Emmanuel Henn
Kenneth`s comment about "Re: WarpUP vs ppc.library test!" was....
KN> Hans Guijt wrote:
KN> >>>- H&P did NOT develop the hardware.
KN> >>True.
KN> >But not quite relevant. Phase5 writes, on their website, that they support
KN> >the development of alternative OSes for the PowerUp. Apparently this doesn't
KN> >include WarpOS.
KN>
KN> But WarpUP isn't a OS _for_ the PowerUp kernal - it's a replacement which
KN> doesn't support PowerUP kernal at all AFAIU. I believe Phase 5 meant that
KN> they support alternative OS'es which _support_ PowerUP kernals (not only the
KN> PowerUP card). Correct me if I'm wrong here.. Anyway:
KN>
KN> I feel H&P did a big mistake not doing a principle communicating with Phase
KN> 5 on this. Personally I think I'll support Phase 5 on this, not only because
KN> of the hard work they have put into this project and their loyalty to the
KN> Amiga community, but since we need a standarisation (on the Amiga) for the
KN> hardware by people who knows the hardware. Maybe Phase 5's standard isn't
KN> the best, but even the longest way starts with a first step.
KN> If H&P had tried to establish a dialog some of H&P's ideas could just maybe
KN> be implemented in PowerUP, but trying to steal the whole cake isn't pretty
KN> popular - that's what Bill You-know-who's company do all the time.
Best would be to hear both sides before judging one, IMHO.
I`ve heard a story by MrX who told me that H&P were SHOWING
the WarpOS to phase5 before they pubished it.
They were discussing with phase5, showed them the better
performance of WarpOS, but phase5 didn`t accept the WarpOS.
They sure did "principle communication", but it seems like
H&P and phase5 have two very different opinions.
But that`s NO reason to act like phase5 do, since the safety
of future software CAN be guaranteed if phase5 tolerates the
WarpOS-solution.
Phase5`s focus is on "open" and "A/BOX", H&P prefer the traditional
Amiga-format, and since there are already some FAST demos of
Voxels, and since the maker of FusionPPC seems ALSO not
to like the phase5-solution, I guess that the developers will rather
not use it, and I BELIEVE that they have got good reasons for their
decisions, it`s not like H&P wants to take control of PowerUP
or something.
They came up with a working and well performing WarpOS, for FREE, and
that shows me that they CARE very much about PowerUP.
And for me, as a user, I don`t care what solution is in the software
I buy (for example TORNADO3D by H&P), as long as it pushes my
(future) PowerUP-card to the max :-)
CU L8TER,
Emmanuel
__
###### ####### ##### ## ## ### ###### ###### A1200/060/18MB
## ## ## ## ## ## ## ## ## ## ## ##Cinema-Fanatic
## ## ###### ## #### ####### ## ## ## ##Doing:PHOENIX
## ## ## ## ## ## ## ## ###### ## ##
###### ####### ##### ## ## ## ## ## ## ###### @HS-HOM.Handshake.de
"BORG? Klingt irgendwie schwedisch..." (First Contact)
Ben Hutchings
In article <61bqa7$bng$1...@news.uni-paderborn.de>,
Ralph Schmidt <la...@basis.owl.de> wrote:
>On 10/06/97, Hans Guijt wrote:
>>Ben Hutchings (worc...@sable.ox.ac.uk) wrote:
>>>This is bad because it means there is no possibility to add support
>for
>>>virtual memory and so on by using an extra hunk to mark programs
>that it
>>>is safe to load-on-demand.
>>
>>So despite the fact that ELF
>>
>>* cannot support Amiga-style libraries
>
>Amiga libraries with the direct knowledge of the applications
>how the interface of a lib has to be accessed was a bad mistake.
>And what have amiga libraries to do with the PPC ? nothing.
>PowerUP will offer dynamic shared libraries in the future.
Why not now? Shared libraries are a *very* important feature of the
AmigaOS.
<snip>
>Maybe you should look at NextStep for an OS with own middleware
>which uses BSD on a Mach Kernel as the basement.
NextStep uses an outdated version of the Mach kernel which has most of
BSD already in there. Later versions of Mach are properly called
micro-kernels and do not have this UNIX stuff built in.
>Or take a look at QNX,Lynx.
>
>Somehow i begin to realize that this is the beginning conflict
>of the people which wanna use their AmigaOS till judgement day
>full with cludges and hacks instead of doing this:
>
>1) use a posix base so you have access to the whole Unix software
> base. A lot drivers through a lot users which write free drivers
> and get the needed informations to write these.
> Doesn´t the majority of people here demand cheap PCI cards
> with a lot drivers ?..any amigaos won´t bring this even with
> PCI when it can´t use the unix driver development resources.
Why use a Posix base? What is wrong with providing a Posix support
layer, like BeOS does? Much as I like UNIX I see that it has many
failings and I don't think it would be at all sensible to change AmigaOS
into a UNIX clone.
>2) base this on a micro/pico kernel which supports realtime like
> task classes.
Fair enough.
>3) and now the key point.
> write a middleware(own gfx system, user interface, datatypes
> like system, rtg(or dig) which use ideas which we liked from
> the AmigaOS.
So you admit that you "liked" (past tense) these in the AmigaOS and do
not care about the future of the official AmigaOS?
>4) Being able to run X11 on the own gfx system...now you also
> have access to all X11 programs but don´t have the need to
> suffer from its problems.
You do not need to run UNIX to be able to run X11. eXceed, AmiWin,
GfxBase's X server and the X server from ADE prove this.
>5) Run an AmigaOS emulation in a virtual enviroment
UAE and AROS exist today; future systems based on a mixture of the two
will likely provide extremeley good and fast emulation on many platforms
for free.
>6) Being able to recompile PowerUP software.
Which there is very little of, and which is likely to be plagued with
problems thanks to the war between H&P and Phase 5.
>AmigaOS in its present form is not able to keep up with the
>processors,system designs and new applications the way it was
>designed and cludging it full with patches won´t change this.
Agreed.
>So the consequence is that a new AmigaOS must be redesigned
>in a big way which wouldn´t look like what you may have known
>from the old AmigaOS API.
Yes, but it seems you would rather have us use Phase5OS rather than
AmigaOS NG.
>Maybe you should take a look at *realtime* systems under Yahoo
>and check out what they use basicly as their base API...they
>at least offer the basic Posix layer...sometimes also the multithread
>Posix layer compliance.
Posix support means you can run a whole lot of UNIX code immediately.
That's great. But you do not have to design your whole OS around this.
>If you don´t like these goals you have to search for the hardware
>and software which will satisfy you in the future.
I doubt it will be coming from Phase 5.
--
Ben Hutchings, compsci&mathmo | ICOAmiga http://www.lapcopaintball.com/icoa/
email/finger m95...@ecs.ox.ac.uk | homepage http://users.ox.ac.uk/~worc0223/
compatible: Gracefully accepts erroneous data from any source
Marcel Jantz
>Anders Melchiorsen <a...@kampsax.dtu.dk> writes:
>>Johan Rönnblom wrote:
>>>
>>> WarpUP vs ppc.library test!
>>
>>doing something useful? It really is of little interest how quick a
>>certain product is at doing absolutely nothing.
>OK then.
>Perhaps YOU can tell us which system is the faster one so that
>we can all ensure that we all develop for the faster one then?
I think it's not that easy. Even if the solution coming from
Haage & Partner is better, faster or what else, they can't simply
ignore phase5 and try to force them into an direction they (phase5)
don't want to go. My guess it that no commercial software developer
can take the risk (or risc :)) to support Haage's solution and ignore
phase5. Doing that what risk future problems with upcoming hardware
features.
BTW: To my experience with the GCC it's not possible to produce
software in an acceptable time frame (due to the time it takes to
compile the sourcecode). Does the GCC coming with the PowerUp board
PPC native or does it run on the 68k CPU?
>TTFN,
>Keith
___________________________________________________________
"Nevertheless smart people still need to eat and pay rent."
Marcel Jantz (McMaJa)
Techn. Support ProDev
Marcel Jantz
>Hi,
>>Anders Melchiorsen <a...@kampsax.dtu.dk> writes:
>>Perhaps YOU can tell us which system is the faster one so that
>>we can all ensure that we all develop for the faster one then?
>How do you think could that be tested? Storm C(++) is just for WarpUp, the
>GNU-stuff is just for the original PowerUp-software AFAIK. Or do you know a
>compiler which exists for both systems?
>No matter how such a test would end, I think it is nearly as dumb as the
>construction of the tower of Babel to develop software for A HACK.
Well, even if it not a HACK (I think phase5 tends to use the word HACK quite
a lot to prevent users from using other people's software) it's for sure
not the correct way to introduce another solution for programming the PPC.
I can imagine how they (Haage) thought of bringing a cool piece of software
as an alternative to the GCC to the Amiga and after getting no support from
phase5 doing it the way they do it now. However, even if I really like the
idea of a small rebel group, I for sure will not use StormC for programming.
One reason is, that as a developer of commercial programs I can't afford
taking the risk of supporting the minority, which for sure has no chance to
survive against the big brother and then of course I already have a
developing system (SAS/C), which is approved to be quite good and of phase5
is telling the truth, will be able to create PPC code in the (near?) future.
>Correct me if I am wrong (or for any other reason...)
Well, again, it was for sure not 'dumb' to create this library for the
StormC compiler, it is simply a try to promote this compiler. Why should
one use it if he/she has alternatives?
>- H&P did NOT develop the hardware.
>- p5 did NOT document it or promise it will not change
>- the H&P "solution" is compatible with NOTHING but H&P products whereas
>- the p5 software uses ELF which is quite common for other PPC systems,
> making cross-development easier and will definitely exist on future PPC
> boards by p5 (if there will be any...)
Well, the last point may not yet be that important and one may say that the
guys from H&P will support that too. However, you are right about the power
of phase5 at this point and I guess, that phase5 will win this fight.
>Even IF the H&P software is a bit faster I see absolutely no reason why
>anyone should use it instead of what the developers of the hardware ship with
>it. Just for the case you are curious: I am NOT paid by p5. And I did not yet
>order a PPC board.
Well, neither do I.
>My personal opinion: WarpUp is FUTILE and DUMB. Try to convince me of the
>opposite :-)
>Bye, Patrick
>--------------------------------------------------------------------------
>Patrick Kursawe Patrick...@ruhr-uni-bochum.de
>Hohenzollernstr. 69 http://www.anachem.ruhr-uni-bochum.de/patrick
>45128 Essen Keep smiling! :-)
>Amiga makes it... well, not possible, but definitely more fun.
Keith Blakemore-Noble
"Marcel Jantz" <m.j...@public.ndh.com> writes:
>>Perhaps YOU can tell us which system is the faster one so that
>>we can all ensure that we all develop for the faster one then?
>
>I think it's not that easy. Even if the solution coming from
>Haage & Partner is better, faster or what else, they can't simply
>ignore phase5 and try to force them into an direction they (phase5)
>don't want to go.
Yeah. I must have been having a funny turn when I wqrote th eabove (that's
what comes of posting after being awake for 72 hours!)
I am of the opinion that H&P seem to be trying to pull a fast one, and trying
to force their compiler to be the standard for PPC, which is a very bad thing,
not to mention a dubious practise...
>BTW: To my experience with the GCC it's not possible to produce
>software in an acceptable time frame (due to the time it takes to
>compile the sourcecode).
On what system are you compiling? Surely it is a bit ott to talk of not
being able to produce in an "acceptible time frame"? I mean even given
that gcc is not the fastest compiler, it certainly doesn't create THAT
much of a problem, does it? It's not as if it takes days to do a compilation :)
> Does the GCC coming with the PowerUp board
>PPC native or does it run on the 68k CPU?
I dunno yet - can';t try it out because a certain company who claimed they
coudl upgrade my Buster in 3 dayshas taken 3 WEEKS to tell me that they can't
get it to work, so I am still waiting for them to return my A4000 so I can send it
to someone else to fix - I just wanna plug in my PPC card!!!
However, I strongly suspect that it runs on the 68k (which in my case will be
a 50MHz 060, so that's not too bad <g> )
TTFN,
Keith
Hans Guijt
Kenneth "Kenny" Nilsen (ke...@bgnett.no) wrote:
>But WarpUP isn't a OS _for_ the PowerUp kernal - it's a replacement which
Their website doesn't specify any such condition, and despite the fact that
I am a registered PowerUp developer I have NO access to any PowerUp
development materials.
>I feel H&P did a big mistake not doing a principle communicating with Phase
>5 on this. Personally I think I'll support Phase 5 on this, not only because
>of the hard work they have put into this project and their loyalty to the
>Amiga community, but since we need a standarisation (on the Amiga) for the
>hardware by people who knows the hardware. Maybe Phase 5's standard isn't
>the best, but even the longest way starts with a first step.
I do not think H&Ps 'loyalty' to the Amiga can be questioned either.
>If H&P had tried to establish a dialog some of H&P's ideas could just maybe
>be implemented in PowerUP, but trying to steal the whole cake isn't pretty
>popular - that's what Bill You-know-who's company do all the time.
In what way are they trying to steal the whole cake, pray tell? You
evidently didn't read my message...
Hans
Ben Hutchings
In article <523.218T74...@cs.tu-berlin.de>,
Tor-Einar Jarnbjo <bj...@cs.tu-berlin.de> wrote:
>On 06-Okt-97 00:07:22, Hans Guijt wrote in comp.sys.amiga.programmer:
>
>>Unfortunately the ELF format does not allow Amiga-style libraries and
>>requires programs to be loaded at absolute addresses. I don't know about you
>>but I do not want to loose libraries just so we can use Windows-based
>>compilers.
>
>Do you seriously claim, that Linux (which also uses ELF-binaries) load
>its programs to absolute addresses?
Yes, absolute *virtual* addresses.
>IMHO, the functionality of shared objects under Unix, is also quite
>similar to the Amiga libraries.
It is not nearly as flexible.
--
Ben Hutchings, compsci&mathmo | ICOAmiga http://www.lapcopaintball.com/icoa/
email/finger m95...@ecs.ox.ac.uk | homepage http://users.ox.ac.uk/~worc0223/
Hans Guijt
Ben Hutchings (worc...@sable.ox.ac.uk) wrote:
>This is bad because it means there is no possibility to add support for
>virtual memory and so on by using an extra hunk to mark programs that it
>is safe to load-on-demand.
So despite the fact that ELF
* cannot support Amiga-style libraries
* cannot support CHIP or FAST hunks
* cannot support relocatable sections
you still prefer it?
>It is hardly a secret that Phase 5 wants people to move on to A\Box, and
>that so far they have only committed to a UNIX-like OS for that.
Correct. But must we accept that as the future of the Amiga?
>I haven't noticed that, and that's because it hasn't been endorsed.
>Amiga Int's webmaster has just copied the blurb sent to him by H&P.
>But you mention an Amiga *Inc* website - where is this?
I'm sorry, I was referring to the Amiga International website, and assuming
that the companies speak with the same voice. My apologies for the confusion.
Hans
Ralph Schmidt
On 10/06/97, Hans Guijt wrote:
>>This is bad because it means there is no possibility to add support
for
>>virtual memory and so on by using an extra hunk to mark programs
that it
>>is safe to load-on-demand.
>
>So despite the fact that ELF
>
>* cannot support Amiga-style libraries
Why should it support Amiga-style libraries ?
Amiga libraries with the direct knowledge of the applications
how the interface of a lib has to be accessed was a bad mistake.
And what have amiga libraries to do with the PPC ? nothing.
PowerUP will offer dynamic shared libraries in the future.
>* cannot support CHIP or FAST hunks
Who cares ?
>* cannot support relocatable sections
That´s wrong.
And besides your rabit like repeatition how evil Phase5 is for
planning to use an OS which will use a Unix base the decision
wasn´t made to use Linux or something else as the base.
And the important thing here is...what is Unix in your mind ?
Maybe you should look at NextStep for an OS with own middleware
which uses BSD on a Mach Kernel as the basement.
Or take a look at QNX,Lynx.
Somehow i begin to realize that this is the beginning conflict
of the people which wanna use their AmigaOS till judgement day
full with cludges and hacks instead of doing this:
1) use a posix base so you have access to the whole Unix software
base. A lot drivers through a lot users which write free drivers
and get the needed informations to write these.
Doesn´t the majority of people here demand cheap PCI cards
with a lot drivers ?..any amigaos won´t bring this even with
PCI when it can´t use the unix driver development resources.
2) base this on a micro/pico kernel which supports realtime like
task classes.
3) and now the key point.
write a middleware(own gfx system, user interface, datatypes
like system, rtg(or dig) which use ideas which we liked from
the AmigaOS.
4) Being able to run X11 on the own gfx system...now you also
have access to all X11 programs but don´t have the need to
suffer from its problems.
5) Run an AmigaOS emulation in a virtual enviroment
6) Being able to recompile PowerUP software.
AmigaOS in its present form is not able to keep up with the
processors,system designs and new applications the way it was
designed and cludging it full with patches won´t change this.
Does anybody here really want to use an OS which is full of
patches/workarounds to fix design problems ?
Wasn´t that what everybody here always critized at MacOS or
Windows3.1/95 ?
So the consequence is that a new AmigaOS must be redesigned
in a big way which wouldn´t look like what you may have known
from the old AmigaOS API.
Maybe you should take a look at *realtime* systems under Yahoo
and check out what they use basicly as their base API...they
at least offer the basic Posix layer...sometimes also the multithread
Posix layer compliance.
If you don´t like these goals you have to search for the hardware
and software which will satisfy you in the future.
--
Ralph Schmidt,la...@popmail.owl.de(private),NextMail welcome
Phase5 ,la...@ufoo.phase5.de(work),NextMail welcome
Eike M. Lang
On 05 Oct 97 19:28:28 +0100, Patrick Kursawe wrote concerning "Re: WarpUP vs ppc.library test!":
> - the H&P "solution" is compatible with NOTHING but H&P products whereas
The H&P solution will support any PPC-board by any manufacturer.
> - the p5 software uses ELF which is quite common for other PPC systems,
> making cross-development easier and will definitely exist on future PPC
> boards by p5 (if there will be any...)
The p5 software will be compatible to nothing but the phase5 PPC-boards.
It will not exist on any PPC-board that will possibly be offered by a
competitor.
> My personal opinion: WarpUp is FUTILE and DUMB. Try to convince me of the
> opposite :-)
You cannot actually judge this before having tested either solution.
--
Eike M. Lang
http://jayhawk.home.pages.de/
PGP-Mail welcome - key available from homepage
Ben Hutchings
In article <4080.721...@inter.nl.net>,
Hans Guijt <hgu...@inter.nl.net> wrote:
<snip>
>On the other hand, the EXECUTABLE format used by H&P is the standard Amiga
>hunkformat, WITHOUT any extensions.
This is bad because it means there is no possibility to add support for
virtual memory and so on by using an extra hunk to mark programs that it
is safe to load-on-demand.
<snip>
>I have a feeling that Phase5 is using this opportunity to get us all to use
>some as yet unspecified UNIX clone. This may be great for them (it
>facilitates development for their A/Box which runs Linux), but it may not be
>so great for us (Amiga users in general).
It is hardly a secret that Phase 5 wants people to move on to A\Box, and
that so far they have only committed to a UNIX-like OS for that.
<snip>
>As a sidenote, has anyone noticed that WarpOS has been endorsed by Amiga
>In[c|t]. on their respective websites?
I haven't noticed that, and that's because it hasn't been endorsed.
Amiga Int's webmaster has just copied the blurb sent to him by H&P.
But you mention an Amiga *Inc* website - where is this?
--
Ben Hutchings, compsci&mathmo | ICOAmiga http://www.lapcopaintball.com/icoa/
email/finger m95...@ecs.ox.ac.uk | homepage http://users.ox.ac.uk/~worc0223/
Software engineering is programming for those who can't. - Dijkstra
Carl Skedinger
Eike M. Lang wrote:
>
> On 05 Oct 97 19:28:28 +0100, Patrick Kursawe wrote concerning "Re: WarpUP vs ppc.library test!":
>
> > - the H&P "solution" is compatible with NOTHING but H&P products whereas
>
> The H&P solution will support any PPC-board by any manufacturer.
Have they announced support for any other board?:)
Ok, then I wnat support for a motorola powerstack motherboard.
> > - the p5 software uses ELF which is quite common for other PPC systems,
> > making cross-development easier and will definitely exist on future PPC
> > boards by p5 (if there will be any...)
>
> The p5 software will be compatible to nothing but the phase5 PPC-boards.
> It will not exist on any PPC-board that will possibly be offered by a
> competitor.
What are your sources for this?
Phase5 or the new manufacturer will just have to make drivers for the
HAL. Shouldn't be harder than writing a new warp.library.
> > My personal opinion: WarpUp is FUTILE and DUMB. Try to convince me of the
> > opposite :-)
>
> You cannot actually judge this before having tested either solution.
The concept can still be futile and dumb.:)
/Calle
--
------------------------------------------------------------------------
Calle Skedinger e92...@e.kth.se
Jaco Schoonen
Keith Blakemore-Noble wrote:
>
> Anders Melchiorsen <a...@kampsax.dtu.dk> writes:
> >Johan Rönnblom wrote:
> >>
> >> WarpUP vs ppc.library test!
> >
> >Will people ever stop doing benchmarks and instead spend their time
> >doing something useful? It really is of little interest how quick a
> >certain product is at doing absolutely nothing.
>
> OK then.
>
> we can all ensure that we all develop for the faster one then?
>
> Keith
I suggest we develop for the BEST system, which is not necessarily the
fastest.
I'd rather have a flexible solution to make sure that applications will
run on all current and future models....
Just my DFL0.02 of course...
--
Jaco Schoonen
Work: qq...@oce.nl
Private: jaco.s...@topic.nl
####################################################################
# #
# This note does not necessarily represent the position of Oce #
# Technologies B.V. Therefore no liability or responsibility for #
# whatever will be accepted. #
# #
####################################################################
Trond Werner Hansen
On 6 Oct 1997, Ralph Schmidt wrote:
> 3) and now the key point.
> write a middleware(own gfx system, user interface, datatypes
> like system, rtg(or dig) which use ideas which we liked from
> the AmigaOS.
Can I write this one, Ralph? Gonk Gonk! ;)
Trond.
Trond Werner Hansen
On Tue, 7 Oct 1997, Colin Ward wrote:
> Well I've got mine, and it damn fast! But not stable. Any Phase 5
> software you run that uses the PPC and their ppc.library will be followed
> soon after by a crash. Phase 5 make some damn good hardware but they are
> totally useless at software writing. Just witness CyberGraphX and how
> badly it is programmed.
Have you seen the CGX sources? no. Do you know how it really works?
probably not. What you write is just BS. Stop turning your own fucked up
view into facts.
Trond.
Ralph Schmidt
On 10/07/97, Ben Hutchings wrote:
>In article <61bqa7$bng$1...@news.uni-paderborn.de>,
>Ralph Schmidt <la...@basis.owl.de> wrote:
support
>>for
>>>>virtual memory and so on by using an extra hunk to mark programs
>>that it
>>>>is safe to load-on-demand.
>>>
>>>
>>>* cannot support Amiga-style libraries
>>
>>Why should it support Amiga-style libraries ?
>>Amiga libraries with the direct knowledge of the applications
>>how the interface of a lib has to be accessed was a bad mistake.
>>And what have amiga libraries to do with the PPC ? nothing.
>>PowerUP will offer dynamic shared libraries in the future.
>
>AmigaOS.
>
The way Amiga libraries are implemented was not a good idea.
Applications know how libraries are build up and use this
knowledge in their code.(Jsr x(a6)) for example...that´s bad.
I prefer dynamic shared link libraries to avoid such problems.
><snip>
>
>>Maybe you should look at NextStep for an OS with own middleware
>>which uses BSD on a Mach Kernel as the basement.
>
>NextStep uses an outdated version of the Mach kernel which has most
of
>BSD already in there. Later versions of Mach are properly called
>micro-kernels and do not have this UNIX stuff built in.
>
Does it matter that it uses an old BSD layer ? No...
the point of the story was that systems like NextStep also use
a Unix layer with a very attractive User Interface.
>>Or take a look at QNX,Lynx.
>>
>>Somehow i begin to realize that this is the beginning conflict
>>of the people which wanna use their AmigaOS till judgement day
>>full with cludges and hacks instead of doing this:
>>
>>1) use a posix base so you have access to the whole Unix software
>> base. A lot drivers through a lot users which write free drivers
>> and get the needed informations to write these.
>> Doesn´t the majority of people here demand cheap PCI cards
>> with a lot drivers ?..any amigaos won´t bring this even with
>> PCI when it can´t use the unix driver development resources.
>
>Why use a Posix base? What is wrong with providing a Posix support
>layer, like BeOS does? Much as I like UNIX I see that it has many
>failings and I don't think it would be at all sensible to change
AmigaOS
>into a UNIX clone.
To get access to applications, drivers, working networking code and
good filesystems.
These things won´t fall from heaven and every new AmigaOS will have
major software problems when it´s not compatible to a huge software
pool.
So what´s bad about some Unix Server und a micro-kernel which gives
you all this and which you don´t really access with new software
because these goes through the new interface.
And by the way...it´s not a Unix clone...not from you and a lot
people understand by Unix. You and a lot people seem to think
Unix means X11 UserInterface and weird APIs.
>
>>2) base this on a micro/pico kernel which supports realtime like
>> task classes.
>
>Fair enough.
>
>>3) and now the key point.
>> write a middleware(own gfx system, user interface, datatypes
>> like system, rtg(or dig) which use ideas which we liked from
>> the AmigaOS.
>
>So you admit that you "liked" (past tense) these in the AmigaOS and
do
>not care about the future of the official AmigaOS?
>
You must know more than us about an *official* AmigaOS ?
And what tells you that when there´s an official new AmigaOS
it wouldn´t go that route ?
I think this route is what makes the most sense for a new
AmigaOS. Basicly the same route would be taking a micro/pico Kernel.
Write the whole IO/DRIVER/NETWORK layer yourself which is no
trivial task(people and time) and basicly have the same in
functionality you already get with the way i suggested.
All that with no development base...with the way i propose you
can start with a Unix and program your middleware and work
on the realtime/micro-kernel function offerings in the other
team...another team can work about making the NetWork config
files be accessable by GUI tools..and intelligent GUI Installers.
This way it would also be possible to get OpenStep(Rhapsody)
from Apple and use also their applications on a new system
which follows more the Amiga philosophy.
Another problem is..which amiga software is actually really
worth it to be ported ? Do you think a new PPC System could
live from this shortage of software which some of the few
active developers port ? That´s like 1985/86 then and I can´t
see how this can afforded again in the today market.
And actually...if the middleware works it´s no problem to
use the kernel you want. It would even be possible to use
a very small kernel without the Unix server so you can run
it on PDAs
>>4) Being able to run X11 on the own gfx system...now you also
>> have access to all X11 programs but don´t have the need to
>> suffer from its problems.
>
>You do not need to run UNIX to be able to run X11. eXceed, AmiWin,
>GfxBase's X server and the X server from ADE prove this.
Don´t you think i don´t know that..but at least you have a working
networking layer then where you don´t have to fight a lot with
ixemul:-) and it´s easier to convert new X11 releases.
>
>>5) Run an AmigaOS emulation in a virtual enviroment
>
>UAE and AROS exist today; future systems based on a mixture of the
two
>will likely provide extremeley good and fast emulation on many
platforms
>for free.
>
Why not...
>>6) Being able to recompile PowerUP software.
>
>Which there is very little of, and which is likely to be plagued with
>problems thanks to the war between H&P and Phase 5.
>
Do you think we were pleased when H&P initiated this ?
Definitely not.
>>AmigaOS in its present form is not able to keep up with the
>>processors,system designs and new applications the way it was
>>designed and cludging it full with patches won´t change this.
>
>Agreed.
>
>>So the consequence is that a new AmigaOS must be redesigned
>>in a big way which wouldn´t look like what you may have known
>>from the old AmigaOS API.
>
>Yes, but it seems you would rather have us use Phase5OS rather than
>AmigaOS NG.
>
You jump to conclusion you can´t know.
And let´s assume Gateway wants something different...fine...why do you
think they don´t change their amiga opinion after their business
problems continue like in this quarter ?
We have also no problem to work together with Gateway on the
development of a *new* AmigaOS...the point is it must be *new*
and not some evolutionary AmigaOS M68k goes PPC cludge.
>>Maybe you should take a look at *realtime* systems under Yahoo
>>and check out what they use basicly as their base API...they
>>at least offer the basic Posix layer...sometimes also the
multithread
>>Posix layer compliance.
>
>Posix support means you can run a whole lot of UNIX code immediately.
>That's great. But you do not have to design your whole OS around
this.
What´s the difference here ?..design around posix ? That´s the I/O
HAL a new program has nothing to do with because that´s the job
of the middleware to offer a nice API.
Ralph Schmidt
On 10/07/97, Staf Verhaegen wrote:
>Ralph Schmidt wrote:
>> =
>
>> AmigaOS in its present form is not able to keep up with the
>> processors,system designs and new applications the way it was
>> Does anybody here really want to use an OS which is full of
>> patches/workarounds to fix design problems ?
>> Windows3.1/95 ?
>> So the consequence is that a new AmigaOS must be redesigned
>> from the old AmigaOS API.
>> and check out what they use basicly as their base API...they
>> at least offer the basic Posix layer...sometimes also the
multithread
>> Posix layer compliance.
>
>> If you don=B4t like these goals you have to search for the hardware
>> and software which will satisfy you in the future.
>
>
>I think C.Sassenrath would slam his head against the wall if he would
>read this :-) (Just my 2 cents)
From my talks with Carl in April on irc it was also quite obvious
that he also thinks that the old AmigaOS API is a thing of the
past.
We think that an Unix Server/Posix layer is the best thing to
solve the obvious money,time and market problems by redesigning
the wheel. The amiga market is in no position to expect millions
be transfered into a complete new OS written by scratch with the
PCI driver support and the money to finance the new software a
new system needed.
And anyway..you ignored the middleware approach explaination where
the Kernel isn愒 that important so that it could be replaced or
whatever in the future(If there愀 a real need for this).
Trond Werner Hansen
On 7 Oct 1997, Ed Collins wrote:
> > > totally useless at software writing. Just witness CyberGraphX and how
> > > badly it is programmed.
> >
> > Have you seen the CGX sources? no. Do you know how it really works?
> > probably not. What you write is just BS. Stop turning your own fucked up
> > view into facts.
>
> Do you have a PPC board ? If it crashes a lot it is because it is
> badly programmed and so it shows that Phase 5 just can't write decent
> software even for their own PPC boards. So Trond stop throwing insults
> to try to make it look that you know what you are taling about.
This is silly. I was talking about CGX, which you (like I quoted)
said was badly programmed. And that's BS. When you stop spreading things
like that, I'll stop the insults. BTW: my mail was pretty clear about it
talking about cgx, not ppc.
Trond.
Ed Collins
> On Tue, 7 Oct 1997, Colin Ward wrote:
>
> > Well I've got mine, and it damn fast! But not stable. Any Phase 5
> > software you run that uses the PPC and their ppc.library will be followed
> > soon after by a crash. Phase 5 make some damn good hardware but they are
> > badly it is programmed.
>
> Have you seen the CGX sources? no. Do you know how it really works?
> probably not. What you write is just BS. Stop turning your own fucked up
> view into facts.
Do you have a PPC board ? If it crashes a lot it is because it is
badly programmed and so it shows that Phase 5 just can't write decent
software even for their own PPC boards. So Trond stop throwing insults
to try to make it look that you know what you are taling about.
Carl Skedinger
Ben Hutchings wrote:
>
> >Maybe you should look at NextStep for an OS with own middleware
> >which uses BSD on a Mach Kernel as the basement.
>
> NextStep uses an outdated version of the Mach kernel which has most of
> BSD already in there. Later versions of Mach are properly called
> micro-kernels and do not have this UNIX stuff built in.
It is great that phase5 have chosen a later Machkernel(3.0/RT/4.0/?)
then, don't you think? :)
(Ok, I'm only guessing they will use a Mach kernel, but more things
are indicating this all the time :)
> >4) Being able to run X11 on the own gfx system...now you also
> > have access to all X11 programs but don´t have the need to
> > suffer from its problems.
>
> You do not need to run UNIX to be able to run X11. eXceed, AmiWin,
> GfxBase's X server and the X server from ADE prove this.
Just realize that there is a difference from using X11lib with
your own toolbox, rather than using an X server based on Motif or
OpenLook (both using XToolkit).
Motif and OpenLook are ugly, clumsy and generally not nice at all:).
If you write your own gui-library on top of Xlib, you get the best
of both worlds: the gui the way you like it and ablity to run Xwin
programs using Openlook or motif (remotely or locally)...
> >5) Run an AmigaOS emulation in a virtual enviroment
>
> UAE and AROS exist today; future systems based on a mixture of the two
> will likely provide extremeley good and fast emulation on many platforms
> for free.
Not as fast as in a virtual enviroment (well maybe for AROS, but then
you can't use programs from other OSes at the same time).
> >6) Being able to recompile PowerUP software.
>
> Which there is very little of, and which is likely to be plagued with
> problems thanks to the war between H&P and Phase 5.
How many programs did you expect? The boards has only been out
a couple of weeks...:)
> >So the consequence is that a new AmigaOS must be redesigned
> >in a big way which wouldn´t look like what you may have known
> >from the old AmigaOS API.
>
> Yes, but it seems you would rather have us use Phase5OS rather than
> AmigaOS NG.
From what you can read on there site, I believe phase5 has made
alot of good choices (in regards to the OS, at least).
> >If you don´t like these goals you have to search for the hardware
> >and software which will satisfy you in the future.
>
> I doubt it will be coming from Phase 5.
Well, that is your personal opinion.
Hans Guijt
Ralph Schmidt (la...@basis.owl.de) wrote:
**************************************************
* *
* >Why should it support Amiga-style libraries ? *
* *
**************************************************
(placed in a box for extra highlight)
Because Amiga libraries are what makes AmigaOS, and AmigaOS is what we Amiga
users want. If we wanted Linux we would have bought PCs a long time ago.
>Amiga libraries with the direct knowledge of the applications
>how the interface of a lib has to be accessed was a bad mistake.
Not at all, it was a BRILLIANT idea.
Mindlessly copying Linux, now THERE is a bad mistake...
>And what have amiga libraries to do with the PPC ? nothing.
EVERYTHING. Amiga libraries are the cornerstone of AmigaOS, now and
hopefully in the future.
>PowerUP will offer dynamic shared libraries in the future.
ELF-style I suppose? I'll take the H&P offering, thank you VERY much.
>>* cannot support CHIP or FAST hunks
>Who cares ?
Amiga users do.
>And besides your rabit like repeatition how evil Phase5 is for
>planning to use an OS which will use a Unix base the decision
>wasn´t made to use Linux or something else as the base.
Could you write shorter sentences please? Your are totally incomprehensible.
You seem to be saying that your OS isn't based on UNIX, which is in direct
contradiction to MANY earlier statements by Phase5. Indeed, some of them are
still on your website.
>And the important thing here is...what is Unix in your mind ?
Cryptic. Limited. Full of features that have no place on the Amiga, but
lacking features that makes the Amiga what it is. Replacing AmigaOS by UNIX
is like replacing excitement by tedium.
>Somehow i begin to realize that this is the beginning conflict
>of the people which wanna use their AmigaOS till judgement day
>full with cludges and hacks instead of doing this:
Let me tell you WHY. We want to use it because AmigaOS is a superb OS that
was exceptionally well-designed. AmigaOS was MEANT to be extendable - you
can claim it is a disadvantage, but that is simply another lie.
The OS shouldn't a HUGE monolith noone is allowed to touch (which is what
Phase5 want for the A/Box - source, your VERY OWN WEBPAGES.) It should be a
collection of loosely coupled modules, like AmigaOS is today. Read just
about any book on software engineering, and you'll see I am right.
>1) use a posix base so you have access to the whole Unix software
> base. A lot drivers through a lot users which write free drivers
> and get the needed informations to write these.
False argument. Running UNIX will not magically make any drivers available
to us. Certainly, hardware manufacturers will not magically start to support
us just because we are now running UNIX instead of AmigaOS.
> Doesn´t the majority of people here demand cheap PCI cards
> with a lot drivers ?..any amigaos won´t bring this even with
> PCI when it can´t use the unix driver development resources.
Sure it can. Give me a simple way to add those cards to my machine and I can
take UNIX sources and convert them to the Amiga, usually quite simple.
>3) and now the key point.
> write a middleware(own gfx system, user interface, datatypes
> like system, rtg(or dig) which use ideas which we liked from
> the AmigaOS.
Not good enough. You have already dropped the entire AmigaOS design. You
have dropped exec. You have dropped SetFunction(). You have dropped the
devices. Giving us a few Amiga-like features doesn't fool me.
>4) Being able to run X11 on the own gfx system...now you also
> have access to all X11 programs but don´t have the need to
> suffer from its problems.
Is intuition not good enough for you?
>5) Run an AmigaOS emulation in a virtual enviroment
Yeah right. Why would I invest a lot of money in a PowerUp board when I can
do all those things on a much cheaper Linux PC today, tell me that?
>6) Being able to recompile PowerUP software.
Not having to write PowerUp software in the first place would be better.
Ralph, you have to understand that NOT EVERYONE SHARES YOUR VISION OF UNIX
AS THE ONLY POSSIBLE FUTURE. The H&P solution offers a future WITH AmigaOS,
unlike the Phase5 solution.
>AmigaOS in its present form is not able to keep up with the
>processors,system designs and new applications the way it was
>designed and cludging it full with patches won´t change this.
Untrue. Look how AROS is shaping up. Look at how easily H&P implemented
their WarpOS.
>Does anybody here really want to use an OS which is full of
>patches/workarounds to fix design problems ?
It is MUCH preferable to running UNIX.
>Wasn´t that what everybody here always critized at MacOS or
>Windows3.1/95 ?
Actually we criticized them for being crap in general. Now we are doing the
same thing to UNIX.
>So the consequence is that a new AmigaOS must be redesigned
>in a big way which wouldn´t look like what you may have known
>from the old AmigaOS API.
Fine, you can do it without me.
>If you don´t like these goals you have to search for the hardware
>and software which will satisfy you in the future.
Let me tell you what my search came up with:
* I have put my order for a PowerUp board on hold, until this mess has been
cleaned up.
* If Phase5 becomes the clear winner I will not order a PowerUp board.
* If H&P becomes the clear winner I will order the board after all.
* If Amiga Int decides the future of the Amiga lies with UNIX I will sell my
Amiga and buy a PC. I will forget the Amiga ever existed. If I cannot use
AmigaOS I will go mainstream, because they at least have good games, cheap
hardware, and massive processing power. So what if it crashes 6 times per
day...
My God, this is the FIRST time I ever seriously considered dumping my
Amiga...
Hans
Hans Guijt
Trond Werner Hansen (tro...@stud.ntnu.no) wrote:
>Have you seen the CGX sources? no. Do you know how it really works?
I suppose he just counted the crashes. That usually serves as a fair
indicator of crappynes when it comes to software.
It hurts, doesn't it, when someone says your program isn't too good?
Hans
Hans Guijt
Ralph Schmidt (la...@basis.owl.de) wrote:
>We think that an Unix Server/Posix layer is the best thing to
>solve the obvious money,time and market problems by redesigning
>the wheel. The amiga market is in no position to expect millions
No, the only way to do that is by implementing the PowerUp with Intel chips
and start running Windows. If you think ANY other tactic will bring in
software you are sadly mistaken.
Hans
Hans Guijt
Keith Blakemore-Noble (Am...@computer.org) wrote:
>I am of the opinion that H&P seem to be trying to pull a fast one, and trying
>to force their compiler to be the standard for PPC, which is a very bad
>thing, not to mention a dubious practise...
No, it is becoming increasingly clear that H&P want the future Amiga to be
an Amiga, while Phase5's only interest is in getting us all to run UNIX.
Read the H&P website, and the various articles posted here by Ralph Schmidt.
Hans
Ralph Schmidt
Hans...are you paid for this massive flaming ? Where in my followup
to your several anti phase5 articles did i flame you personally.
I suspect though that you´re somehow connected to Mr. Vermeulen
and H&P after what you´re doing here.
I simply posted what our goals are...no need to flame and expecially
not with such weak and false arguments.
I have no time to argue with you on this level...
So go the H&P way...wait for the hardware which will support them
and feel happy that way. We´re doing our business.
Keith Blakemore-Noble
Oh, I have.
And I am increasingly convinced of the correctness of my opinion above,
I'm afraid.
TTFN,
Keith.
Stefan Boberg
> >Applications know how libraries are build up and use this
>
> You have got to be kidding. This can only mean you NEVER understood how
> libraries work in the first place.
Umm.. I think Ralph understands a bit about it.
> The jumptable is an abstracted version of
> the functionality in the library.
Come again? Like, how? Does it matter WHEN the function address is
resolved? How is it better to have a call such as:
JSR -108(a6)
Compared to:
JSR xxxxx
There's no functional difference, and to be honest I think you'll find
that the latter approach would be faster on PPC.
>It can be manipulated by the OS in several
> ways, and is *the only valid API* to Amiga libraries.
How would the library be 'manipulated' by the OS, and why should that
be necessary?
> jsr (a6,x) bad? Man, you have completely lost it. That is precisely how it
> is supposed to work.
So why is it that AmigaOS is the only OS that uses this approach? Are
ALL other OS designers idiots?
> >We have also no problem to work together with Gateway on the
> >development of a *new* AmigaOS...the point is it must be *new*
> >and not some evolutionary AmigaOS M68k goes PPC cludge.
>
> In other words, it must be YOUR solution and they have no say in what their
> own future OS is going to look like.
Have you programmed for AmigaDOS? Did you use some secret API that I
didn't know about? I found it very hard to do anything complex with it.
It's a right pain. I'm not saying it's all crap -- it's just
under-powered and it's not a very modern or elegant design.
--
=====================================================================
Stefan Boberg "My priceless collection of
bob...@team17.com incurable diseases... Violated!" - Ren
Keith Blakemore-Noble
Hans Guijt <hgu...@inter.nl.net> writes:
>Trond Werner Hansen (tro...@stud.ntnu.no) wrote:
>>Have you seen the CGX sources? no. Do you know how it really works?
>
>I suppose he just counted the crashes. That usually serves as a fair
>indicator of crappynes when it comes to software.
Y'know, it's rather strange.
I seem to recall people making the point that they experience crashes
onother software due to MUI, yet you refused to believe that MUI was the
cause...
Just an observation.
TTFN,
Keith.
Tor-Einar Jarnbjo
On 06-Okt-97 23:30:25, Ben Hutchings wrote in comp.sys.amiga.programmer:
>In article <523.218T74...@cs.tu-berlin.de>,
>Tor-Einar Jarnbjo <bj...@cs.tu-berlin.de> wrote:
>>On 06-Okt-97 00:07:22, Hans Guijt wrote in comp.sys.amiga.programmer:
>>
>>>Unfortunately the ELF format does not allow Amiga-style libraries and
>>>requires programs to be loaded at absolute addresses. I don't know about
>>>you but I do not want to loose libraries just so we can use Windows-based
>>>compilers.
>>
>>Do you seriously claim, that Linux (which also uses ELF-binaries) load
>>its programs to absolute addresses?
>Yes, absolute *virtual* addresses.
Which is something else. I assume, that a future AmigaOS will support
virtual memory, and must therefore be able to support virtual addresses.
And, since this is possible on both the 68060 and the PPC, I can't
see any problems with this.
>>IMHO, the functionality of shared objects under Unix, is also quite
>>similar to the Amiga libraries.
>It is not nearly as flexible.
Well, I must admit, that I've never programmed an AmigaOS library, but
I've used it from the API-side, and I've used Unix libraries, and I
can't see many differences. Why don't you give some examples.
Tor-Einar
Johan Ronnblom
Ralph Schmidt wrote:
> Please read again what i said.
> The way Amiga libraries are implemented was not a good idea.
> Applications know how libraries are build up and use this
> I prefer dynamic shared link libraries to avoid such problems.
Problems? In what way is that a problem? It is very efficient on
CPU and memory usage, and where is the great problem?
Like Hans said in another thread, 76 copies of the same code is not a
good thing!
> We have also no problem to work together with Gateway on the
> development of a *new* AmigaOS...the point is it must be *new*
> and not some evolutionary AmigaOS M68k goes PPC cludge.
Still, that might be a better solution than a 'UNIX goes
AmigaOS'-kludge.
Personally, I like AmigaOS a lot better than UNIX, and I think memory =
protection, multiprocessing and multiuser capabilities *could* be
integrated into AmigaOS. It would not be easy, but maybe easier than
integrating the AmigaOS advantages into UNIX..
/Johan R=F6nnblom, Team Amiga
Colin Ward
"Kenneth "Kenny" Nilsen" <ke...@bgnett.no> wrote:
>Emmanuel Henn wrote:
>[...]
>>And for me, as a user, I don`t care what solution is in the software
>>I buy (for example TORNADO3D by H&P), as long as it pushes my
>>(future) PowerUP-card to the max :-)
>Ok, well, I am first interrested to hear reports from people using the
>PowerUp cards. If they work well, how fast, stable etc. Then I hope there
>will be a solution on the WarpUP vs PowerUP "situation". In the mean time I
>will joy my Amiga as-is :)
Well I've got mine, and it damn fast! But not stable. Any Phase 5
software you run that uses the PPC and their ppc.library will be followed
soon after by a crash. Phase 5 make some damn good hardware but they are
totally useless at software writing. Just witness CyberGraphX and how
badly it is programmed. Leave the software to someone else and stick to
hardware I say. And that's from someone *with* a PowerPC!
/----------------------------------------------------------------------\
[Hitman/Code HQ - 6502/68000/604e coder - Long live the Amiga! ]
[VZ-200/Vic-20/c64*6/c128/Amiga CD32/500/2000/1200*2/4000 - 6581 Rulez!]
[A4000/CV64-3D/060-50/604e-200/66 Meg. Does not own a PC! ]
[After three days without coding, life becomes meaningless. ]
\----------------------------------------------------------------------/
Staf Verhaegen
Ralph Schmidt wrote:
> =
> AmigaOS in its present form is not able to keep up with the
> processors,system designs and new applications the way it was
> designed and cludging it full with patches won=B4t change this.
> Does anybody here really want to use an OS which is full of
> patches/workarounds to fix design problems ?
> Wasn=B4t that what everybody here always critized at MacOS or
> Windows3.1/95 ?
> So the consequence is that a new AmigaOS must be redesigned
> in a big way which wouldn=B4t look like what you may have known
> from the old AmigaOS API.
> Maybe you should take a look at *realtime* systems under Yahoo
> and check out what they use basicly as their base API...they
> at least offer the basic Posix layer...sometimes also the multithread
> Posix layer compliance.
> =
> If you don=B4t like these goals you have to search for the hardware
> and software which will satisfy you in the future.
> =
I think C.Sassenrath would slam his head against the wall if he would
read this :-) (Just my 2 cents)
Actually the current POSIX (UNIX) standards are also a bunch of kludges
to the original. In the beginning one program was running on one
machine. Then they used a kludge with the MMU to be able to run more
than one program at the same moment, each in his virtual evironment.
Than a new kludge to allow shared memory between different applications.
Than a new kludge to allow multithreading of applications, the X kludge,
and so on.
The only thing I want to make clear is that kludges are not necesarry
bad for an OS. It's just the natural evolution to an OS with more
features.
It is true the AmigaOS is not up to date: virtual memory, some memory
protection, ... But I think it can be included with some 'kludges' in
AmigaOS4. But I like the Amiga way of doing things. The programs for the
amiga are designed with multitasking in mind: shared devices, libraries,
shatterloading of relocatable code. Which result in a very efficient
multitasking operating system. If you like the UNIX way more install
LINUX or NetBSD or some other UNIX clone but don't try to force us,
amiga freaks, to use a UNIX (POSIX) based system with an Amiga emulator
on top of it (A/Box, PIOS maybe, ...). =
> --
> Ralph Schmidt,la...@popmail.owl.de(private),NextMail welcome
> Phase5 ,la...@ufoo.phase5.de(work),NextMail welcome
-- =
------------------------------------------------------------------------
Staf Verhaegen
IMEC vzw. - ASP/TCAD tel: (32)-(0)16/28 12 38
Kapeldreef 75 fax: (32)-(0)16/28 12 14
3001 Leuven (Belgium) email: verh...@imec.be
------------------------------------------------------------------------
For every tool there are at least 2 uses: the one it was designed for
and the other for which it wasn't.
Michael Rock
Keith Blakemore-Noble wrote:
> Yeah. I must have been having a funny turn when I wqrote th eabove (that's
> what comes of posting after being awake for 72 hours!)
>
> I am of the opinion that H&P seem to be trying to pull a fast one, and trying
> to force their compiler to be the standard for PPC, which is a very bad thing,
> not to mention a dubious practise...
WarpUp is transparent for any other compiler that wants to run with it.
The WarpUp V7 works well with the phase5 software and is as stable as
the rest of that system.
> >BTW: To my experience with the GCC it's not possible to produce
> >software in an acceptable time frame (due to the time it takes to
> >compile the sourcecode).
>
> On what system are you compiling? Surely it is a bit ott to talk of not
> being able to produce in an "acceptible time frame"? I mean even given
> that gcc is not the fastest compiler, it certainly doesn't create THAT
> much of a problem, does it? It's not as if it takes days to do a compilation :)
>
> > Does the GCC coming with the PowerUp board
> >PPC native or does it run on the 68k CPU?
>
> I dunno yet - can';t try it out because a certain company who claimed they
> coudl upgrade my Buster in 3 dayshas taken 3 WEEKS to tell me that they can't
> get it to work, so I am still waiting for them to return my A4000 so I can send it
> to someone else to fix - I just wanna plug in my PPC card!!!
It is 68k, the same as found on the ADE.
> However, I strongly suspect that it runs on the 68k (which in my case will be
> a 50MHz 060, so that's not too bad <g> )
>
> TTFN,
> Keith
--
Michael Rock, student of computer science, TU Braunschweig.
Also at
Haage & Partner PPC-RISC Compiler department.
contact me at
m.r...@haage-partner.com
A3oooT 060@50 + 604e@200
Hans Guijt
Colin Ward (co...@leprechaun.com.au) wrote:
> Well I've got mine, and it damn fast! But not stable. Any Phase 5
>software you run that uses the PPC and their ppc.library will be followed
>soon after by a crash. Phase 5 make some damn good hardware but they are
How about the H&P software?
Hans
Hans Guijt
Tor-Einar Jarnbjo (bj...@cs.tu-berlin.de) wrote:
>Do you seriously claim, that Linux (which also uses ELF-binaries) load
>objects under Unix, is also quite similar to the Amiga libraries.
Yes, I do. It can do that because Linux systems are equipped with MMU and
virtual memory, and can basically load every application starting at address
0. This is NOT compatible with AmigaOS though.
Hans
Hans Guijt
I read it again and you still appeared to be talking out of your ass.
>The way Amiga libraries are implemented was not a good idea.
>Applications know how libraries are build up and use this
>knowledge in their code.(Jsr x(a6)) for example...that愀 bad.
You have got to be kidding. This can only mean you NEVER understood how
libraries work in the first place. The jumptable is an abstracted version of
the functionality in the library. It can be manipulated by the OS in several
ways, and is *the only valid API* to Amiga libraries.
jsr (a6,x) bad? Man, you have completely lost it. That is precisely how it
is supposed to work.
>I prefer dynamic shared link libraries to avoid such problems.
Pray tell, what is the problem with jsr (a6,x)? How would a library be
called in your system (which apparently knows nothing about the library)?
>the point of the story was that systems like NextStep also use
>a Unix layer with a very attractive User Interface.
You don't get it. You cannot give us a lollypop to keep us quiet and in the
meantime replace the OS we love by the crap that is UNIX.
>Another problem is..which amiga software is actually really
>worth it to be ported ? Do you think a new PPC System could
>live from this shortage of software which some of the few
>active developers port ? That愀 like 1985/86 then and I can愒
>see how this can afforded again in the today market.
This is a valid concern, but I doubt that running UNIX will bring in much
software beyond a whole bunch of GNU tools. Most people don't want compilers
and stuff, they want what can only be termed as 'end-user programs'. UNIX
has surprisingly little of those.
>Do you think we were pleased when H&P initiated this ?
>Definitely not.
That much is clear. Unfortunately for you many of us seem to believe that
H&P have a clearer view of the future of the Amiga then you (Phase5) do. We
are not pleased with your attempts to convert us to UNIX.
>You jump to conclusion you can愒 know.
Because Phase5 is not exactly forthcoming with information, is part of the
reason. I am a registered developer (at least, I used to be - of course
since I started arguing against Phase5's software solution I may have had my
license revoked) and there was never ANY information about PowerUp
available. Just some bits about CyberGfx.
>We have also no problem to work together with Gateway on the
>development of a *new* AmigaOS...the point is it must be *new*
>and not some evolutionary AmigaOS M68k goes PPC cludge.
In other words, it must be YOUR solution and they have no say in what their
own future OS is going to look like.
Hans
Trond Werner Hansen
fOn 7 Oct 1997, Hans Guijt wrote:
> I suppose he just counted the crashes. That usually serves as a fair
> indicator of crappynes when it comes to software.
Maybe other factors caused the crashes? How about the majority which
thinks cgx work very well? Their votes don't count?
> It hurts, doesn't it, when someone says your program isn't too good?
I didn't write CGX.
I'm amazed by all these totally destructive and bashing mails, with no
connection to facts and reality. *sigh*
Trond.
Colin Ward
Stefan Boberg <stefan...@team17.com> wrote:
>Hans Guijt wrote:
>> Ralph Schmidt (la...@basis.owl.de) wrote:
>
>> >The way Amiga libraries are implemented was not a good idea.
>> >Applications know how libraries are build up and use this
>> >knowledge in their code.(Jsr x(a6)) for example...that愀 bad.
>>
>> You have got to be kidding. This can only mean you NEVER understood how
>> libraries work in the first place.
> Umm.. I think Ralph understands a bit about it.
>> The jumptable is an abstracted version of
>> the functionality in the library.
> Come again? Like, how? Does it matter WHEN the function address is
>resolved? How is it better to have a call such as:
> JSR -108(a6)
> Compared to:
> JSR xxxxx
> There's no functional difference, and to be honest I think you'll find
>that the latter approach would be faster on PPC.
[snip]
> Have you programmed for AmigaDOS? Did you use some secret API that I
>didn't know about? I found it very hard to do anything complex with it.
>It's a right pain. I'm not saying it's all crap -- it's just
>under-powered and it's not a very modern or elegant design.
I must say that about a year and a half ago, when Escom went broke, I
threw up my hands in despair and left the Amiga (I'm back now, big time :-)
and went PC. Anyway, I started writing my own 32 bit OS in Watcom C and
decided to make it source compatible with AmigaDOS, and the one thing that
troubled me a lot was that the library system used by the Amiga seemed
*very* out of date... So I opted for the Windoze DLL style of loading &
linking the libraries at load time. It's just silly to have to do an
explicit LoadLibrary() on each and every library that you need, checking
return codes, closing the libraries when you're done with them and
outputting error messages when you can't open them. It should all be done
by the OS... Have the library names embedded in the header of your
executable so the OS loads 'em automatically and puts up a requester saying
that it can't find/load one or more of 'em...
Just thought I'd throw in my 2 cents...
Kyzer
Johan Ronnblom, while sobering up, wrote:
: Personally, I like AmigaOS a lot better than UNIX, and I think memory =
: protection, multiprocessing and multiuser capabilities *could* be
: integrated into AmigaOS. It would not be easy, but maybe easier than
: integrating the AmigaOS advantages into UNIX..
1. Would be too much like Apple.
2. 'Another non standard UNIX!'
Besides, it would be a bastard making all libraries not only reentrant but
also now multiuser - and that's a lot of work! You can see why people would
prefer just to tweak an already existing UNIX - it would save a lot of time
and money.
--
Stuart Kyzer Caie, Aberdeen University, Scotland. ...kyzer@4u.net...
My opinions are not those of Aberdeen University, and I do not speak for or
on behalf of AUCC. http://www.abdn.ac.uk/~u13sac/
--
BONUS: Present this .sig at Tesco for a 15% discount.
Rudi Chiarito
Colin Ward (co...@leprechaun.com.au) wrote:
>by the OS... Have the library names embedded in the header of your
>executable so the OS loads 'em automatically and puts up a requester saying
>that it can't find/load one or more of 'em...
This was supported by AmigaDOS up to v1.3, but nobody (or almost nobody)
ever used the feature. IIRC it was also because LoadSeg() opened the libraries
without doing any version check (ie. it would open intuition.library whatever
version it was and the application would still need to check the version number
by itself and prompting the user in case of a library obsolete for the
program's needs).
--
If we make it we can all sit back'n'laugh but I fear tomorrow I'll be crying
Rudi Chiarito - Magrathea & SushiWare Development - Jay Miner Society Member
EMail: chia...@cli.di.unipi.it - WWW: http://www.cli.di.unipi.it/~chiarito/
MISTAKES/MISSPELLINGS ARE FICTIONAL: A SIMILARITY TO REAL ONES IS INCIDENTAL
Emmanuel Henn
Ralph`s comment about "Re: WarpUP vs ppc.library test!" was....
RS> On 10/07/97, Hans Guijt wrote:
RS> >Ralph Schmidt (la...@basis.owl.de) wrote:
RS> >>We think that an Unix Server/Posix layer is the best thing to
RS> >>solve the obvious money,time and market problems by redesigning
RS> >>the wheel. The amiga market is in no position to expect millions
RS> >
RS> >No, the only way to do that is by implementing the PowerUp with Intel
RS> chips
RS> >and start running Windows. If you think ANY other tactic will bring
RS> in
RS> >software you are sadly mistaken.
RS> >
RS>
RS> Hans...are you paid for this massive flaming ? Where in my followup
RS> to your several anti phase5 articles did i flame you personally.
RS> I suspect though that you're somehow connected to Mr. Vermeulen
RS> and H&P after what you're doing here.
RS> I simply posted what our goals are...no need to flame and expecially
RS> not with such weak and false arguments.
RS> I have no time to argue with you on this level...
RS>
RS> So go the H&P way...wait for the hardware which will support them
RS> and feel happy that way.
Well, there`s one chance for phase5: I am going to get myself
H&Ps TORNADO3D, and then I`ll get a PPC-board.
The one that works with Tornado3D is my choice.
If phase5 is stupid enough to destroy their own userbase, that`s
their "business", if I don`t geta phase5-board working with the
Tornado3D, I`ll buy the board of another hardware maker, easy as
that.
It`s NOT phase5 who`s steering, it`s the USERS, so don`t do anything
to makes us upset, because PCs are cheap these days, okay ?
RS> We're doing our business.
Yes, go ahead and do "Your" business, but don`t complain if there
are many people that won`t follow You.
phase5`s got ONE point of view, others have other points of view.
If phase5 shows Gates-manners by excluding any other opinion,
that`s indeed their business, but don`t think that the users
are just mindless followers.
We`ve been waiting way too long .
And I remind You that there are SEVERAL projects in the making that
DON`T use the ppc.lib furnished by phase5 (FUSION, TORNADO3D...).
CU L8TER,
Emmanuel
__
###### ####### ##### ## ## ### ###### ###### A1200/060/18MB
## ## ## ## ## ## ## ## ## ## ## ##Cinema-Fanatic
## ## ###### ## #### ####### ## ## ## ##Doing:PHOENIX
## ## ## ## ## ## ## ## ###### ## ##
###### ####### ##### ## ## ## ## ## ## ###### @HS-HOM.Handshake.de
"The light that burns twice as bright only burns have as long.
And You have burnt so very, very brightly, Roy..."
Thomas Richter
Hi Rudi!
chia...@cli.di.unipi.it (Rudi Chiarito) writes:
>Colin Ward (co...@leprechaun.com.au) wrote:
>>by the OS... Have the library names embedded in the header of your
>>executable so the OS loads 'em automatically and puts up a requester saying
>>that it can't find/load one or more of 'em...
>This was supported by AmigaDOS up to v1.3, but nobody (or almost nobody)
>ever used the feature. IIRC it was also because LoadSeg() opened the libraries
>without doing any version check (ie. it would open intuition.library whatever
>version it was and the application would still need to check the version number
>by itself and prompting the user in case of a library obsolete for the
>program's needs).
Well, let's say it in these terms: The documentation of 1.3 said it was
supported, but, in fact, it never was. This implementation was PLANNED, though
never done. The ADos manual used to be, and still is, a mess and completely
unhelpful. (Sorry to say, but that's how it is...)
Why do I know? Once when I was really bored, I made a doc about all BCPL
routines in the 1.3 (v34) ADos and I really STEPPED THRU all routines,
including the LoadSeg() (or, precisely, what is called InternalLoadSeg() today)
routine. Understanding compiled BCPL is not easy, but I found NO, NOT A SINGLE
routine that opens a library from the binary.
In fact, if the second long of a binary is NOT NULL (so, that's the place
where the library names should actually go), even the v34 DOS failed to load
this program. The documentation is simply wrong, that's all. (That goes for
example, too, for the Reloc32Short hunk which had a different number for the
v37-v38 Dos than stated in the manual. That is, BTW, fixed for V39.)
Even worse, the ADos manual states STILL that this feature is supported, but
it isn't, and never was.... (at least, not since v33. I haven't checked
kickstart 1.1 or 1.0, though).
Greetings,
Thomas
______________don't_cut_here,_it_could_damage_your_terminal____________________
_______ _____ _____
/ / / / / / / EMAIL: th...@einstein.math.tu-berlin.de
/ /____/ / / /____/
/ / / / / / \ http://www.math.tu-berlin.de/~thor/thor/index.html
/ / / /____/ / /
_______________________________________________________________________________
Hans Guijt
Ralph Schmidt (la...@basis.owl.de) wrote:
>Hans...are you paid for this massive flaming ? Where in my followup
No, I am devoting a lot of my precious free time to flame you. I _care_, you
see.
>to your several anti phase5 articles did i flame you personally.
Nowhere, but feel free to do so if you think it will help. Or if you don't
want to bother the rest of the group, do it in personal mail. Or perhaps
we'll meet in Koln and you can flame me there. I don't care about that.
I _do_ care about this: we Amiga owners have waited years for something new
and good. For a long time it appeared that Phase5 would give us precisely
what we were looking for: more processing power for our Amigas.
In the end it turns out that they have a completely different plan: Phase5
means to remove AmigaOS in favor of their own UNIX-like kernel. This is much
the same as all those attempts by PC owners to convert us to PC, except that
this time it is coming from the inside. PowerUp is NOT about more CPU power
for our Amigas, it is an attempt to get us to produce UNIX software for your
upcoming A/Box.
I take offense at that because I _care_ about AmigaOS. It is conceptually
sound (unlike most other OSes currently available), offers what I need (and
I am not alone in feeling that way), a joy to use, etc. It was worth
sticking to for all those years without development. It is still worth
sticking to today.
Phase5 is resorting to rethoric and scare-tactics. Your continual assurances
that AmigaOS is 'full of patches and cludges' and 'badly designed' will help
to fix that idea in peoples' mind. It does NOT make it true though! No other
OS is so well thought-out or clean as AmigaOS!
I am bitterly disappointed in Phase5, both attitude and development
direction. My only hope is that Amiga Inc will take control and steer
AmigaOS to the future it deserves instead of an early retirement.
Phase5s statements in this group, particularly those about AmigaOS being
conceptually unsound and those about 'no software being available for the
Amiga that is worth porting' have struck me as utterly arrogant for a
company that is trying to sell hardware to Amiga users. We stuck to the
Amiga all those years - those who wanted something else left long ago. Don't
force us somewhere we don't want to go. Don't try to take away what makes
the Amiga an Amiga.
>So go the H&P way...wait for the hardware which will support them
>and feel happy that way. We´re doing our business.
If you stick by your plans of making your boards incompatible to the H&P
software, don't bother counting me as a customer or as a developer.
Hans
Hans Guijt
Keith Blakemore-Noble (Am...@computer.org) wrote:
>And I am increasingly convinced of the correctness of my opinion above,
>I'm afraid.
Really Keith, now you are just flaming because it is me. Silly boy.
Hans
Jeroen T. Vermeulen
Loading at address 0 would seem logical in a UNIX-like environment (perhaps even
more so on systems that use other numerical values to represent the NULL
pointer), but I don't think ELF supports this particular case. ELF mandates
that zero (ie. not necessarily NULL!) is used as a special case, eg. to mean
"there is no code entry point here". But otherwise, executables in UNIX are
assumed to be masters of their own virtual address space and can define it as
they wish (except for OS- and CPU-specific properties such as where the
forbidden zero data page ends and how large pages are/can be)..
I recall one description, from the ADE people I think, of a particularly
hard-to-port UNIX program which could be reconfigured by starting it with a
special option; it would then load any requested modules of itself into memory
and *snapshot its own memory image to file*. Since the program "knows" that it
will always run in the same environment, and the same environment will always
load everything at the same address so no problem and never mind that relocation
data. Good candidate for Horrible Kludge of the Century if you ask me.
This UNIX property can also be used for attacks on the system: IIRC the "worm"
that once brought down the Internet used a trick where it spilled a mail
program's buffer for something or other. The buffer, a local variable allocated
on the stack, was large enough that it "should be enough for anyone" but not
actually guarded against overruns. So the worm could feed its own data into the
mailer's memory as text (it was actually machine code), and know from experience
exactly where in its virtual address space it would be located. It then
overflowed the buffer so that it spilled over the return address in one of the
mailer's stack frames and replaced it with the address of its worm code. When
the poor function returned, it jumped to the wrong address and executed the
worm's infiltrated code instead of the mailer's... but with root privileges
because it was still part of the mailer's "trusted" process!
But I digress. Shared libraries are different from executables in ELF in that
they can be relocated so they won't clash with the executable that loads them;
so if you want to use ELF in an Amiga-like environment, you'd have to always
generate ELF shared objects instead of proper executables and kludge in a
convention for giving the library an entry point as if it were an executable.
Maybe abuse an initialization routine symbol or something.
Or alternatively, tell the compiler to write position-independent code at the
cost of some performance (assuming that it will let you do this in an
executable) and let the linker emulate a virtual address space just for the
purpose of locating the symbols. That would mean setting up a datastructure to
map virtual addresses to hunk numbers, and for each symbol/address, subtracting
the hunk's virtual base address from the address you're working with, and adding
the hunk's actual memory address. That would be a fairly costly kludge for
reconstructing the hunk/offset pairs you need in an Amiga environment (and IMHO
in any environment that can be called clean in this regard), but I suppose it
could get the job done.
--
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
; Jeroen T. Vermeulen \\"How are we doing?"// Yes, we use Amigas ;
;--- j...@xs4all.nl ---\\"Same as always."//-- ... --;
;jver...@wi.leidenuniv.nl \\"That bad huh?"// Got a problem with that? ;
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
The Pentium was designed to conquer, not to divide
Keith Blakemore-Noble
Hans, try not to flatter yourself.
(1) The above was not a flame, it was a statement of my opinion.
That is differs from your is not, last time I checked, a crime.
It was my opinion, and it is still my opinion, even after considering all of the evidence.
(2) Are you seriously telling me that you believe I form my opinions purely to
disagree with someone whom I have never met, someone abut whom I know nothing
whatsoever, and someone with whom I have exchanged all of about 3 news posts in my
entire life?
Sorry, Hans, but I am afraid you really do place too much importance upon yourself.
Fact - I personally believe that the H&P approach is wrong.
Sorry if you are fundamentally opposed tothe concept of free speech, but that's life.
TTFN,
Keith.
Stefan Boberg
Hans Guijt wrote:
> Amazingly, this _was_ a feature of AmigaOS, but nobody used it so it was
> removed in OS 2.0! Of course, modern Amiga compilers open libraries
> automatically.
Okay I'll bite: can you explain to me exactly WHY it is better to
have shared libraries with jump tables rather than loader fix-ups?
Rask Ingemann Lambertsen
On 07-Okt-97 01:25:32, Ben Hutchings wrote the following about "Re: WarpUP vs ppc.library test!":
> In article <61bqa7$bng$1...@news.uni-paderborn.de>,
> Ralph Schmidt <la...@basis.owl.de> wrote:
>>4) Being able to run X11 on the own gfx system...now you also
>> have access to all X11 programs but don愒 have the need to
>> suffer from its problems.
> You do not need to run UNIX to be able to run X11. eXceed, AmiWin,
> GfxBase's X server and the X server from ADE prove this.
As does the countless of X11 server implementations for Windos, Mac,
dedicated X terminals and God knows what else. X11 _is_ it's own gfx system,
and X11 problems are X11 problems no matter what you run X11 on.
Regards,
/秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤T秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤珮
| Rask Ingemann Lambertsen | E-mail: mailto:ra...@kampsax.dtu.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4k/030, 16 MB, 3 GB, Ariadne | "ThrustMe" on XPilot, ARCnet and IRC |
| Paperweights -- The only way to keep bills down. |
Rask Ingemann Lambertsen
On 07-Okt-97 22:20:43, Stefan Boberg wrote the following about "Re: WarpUP vs ppc.library test!":
> Hans Guijt wrote:
>> Ralph Schmidt (la...@basis.owl.de) wrote:
>
>> >The way Amiga libraries are implemented was not a good idea.
>> >Applications know how libraries are build up and use this
>> >knowledge in their code.(Jsr x(a6)) for example...that愀 bad.
>>
>> You have got to be kidding. This can only mean you NEVER understood how
>> libraries work in the first place.
> Umm.. I think Ralph understands a bit about it.
When he says things like that, you start to wonder (or even question other
things he says)...
>> jsr (a6,x) bad? Man, you have completely lost it. That is precisely how it
>> is supposed to work.
> So why is it that AmigaOS is the only OS that uses this approach? Are
> ALL other OS designers idiots?
That could be one reason. Closer to reality is that they had backward
compatibility issues to consider. There never was such a thing with shared
libraries on the Amiga because they were defined from the beginning. On Un*x
you suddenly had to magically change absolute function calls into calls to
dynamically loaded functions. How do you do that? Well, you patch the binary
at runtime, inserting the correct address as your application fage faults.
Ugly, but there was no other way without changing the function calling
conventions, which wouldn't be compatible.
> Have you programmed for AmigaDOS? Did you use some secret API that I
> didn't know about? I found it very hard to do anything complex with it.
> It's a right pain. I'm not saying it's all crap -- it's just
> under-powered and it's not a very modern or elegant design.
I can't say that I agree with that. While it isn't perfect, it is much easier
to program for that Un*x.
Regards,
/秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤T秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤珮
| Rask Ingemann Lambertsen | E-mail: mailto:ra...@kampsax.dtu.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4k/030, 16 MB, 3 GB, Ariadne | "ThrustMe" on XPilot, ARCnet and IRC |
| I'm as confused as a baby at a topless bar! |
Rask Ingemann Lambertsen
On 07-Okt-97 10:47:03, Ralph Schmidt wrote the following about "Re: WarpUP vs ppc.library test!":
[cut a lot]
> And by the way...it愀 not a Unix clone...not from you and a lot
> people understand by Unix. You and a lot people seem to think
> Unix means X11 UserInterface and weird APIs.
Unix _does_ mean weird APIs. Once you leave it the "Hello world" level, you
run into it pretty quickly. It is the result of feeping creaturism. Try
comparing e.g. the BSD socket interface with ANDI (Holger Kruse's proposed
Aminet networking API), for even such a simple thing as opening a connection
to a remote host. Then try nonblocking sockets and it becomes a nightmare on
Unix.
Regards,
/秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤T秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤秤珮
| Rask Ingemann Lambertsen | E-mail: mailto:ra...@kampsax.dtu.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4k/030, 16 MB, 3 GB, Ariadne | "ThrustMe" on XPilot, ARCnet and IRC |
| Do artificial plants need artificial water? |
Rask Ingemann Lambertsen
On 07-Okt-97 00:56:07, Ralph Schmidt wrote the following about "Re: WarpUP vs ppc.library test!":
> Why should it support Amiga-style libraries ?
Aarrgghh!! That questions scares me. There is a "not" missing, right?
> Amiga libraries with the direct knowledge of the applications
> how the interface of a lib has to be accessed was a bad mistake.
In which way?
>And what have amiga libraries to do with the PPC ? nothing.
>PowerUP will offer dynamic shared libraries in the future.
Shared libraries are a fundamental part of the Amiga OS. As we switch from
m68k to PPC, of course it has something to do with the PPC, and we need them
now.
> AmigaOS in its present form is not able to keep up with the
> processors,system designs and new applications the way it was
> designed and cludging it full with patches won´t change this.
> Does anybody here really want to use an OS which is full of
> patches/workarounds to fix design problems ?
Depends. Would you say that Unix as we know it today is not "an OS which is
full of patches/workarounds to fix design problems"?
Sure I would prefer an OS without design problems, but jump around yourself
three times if you believe such a thing exists.
> Wasn´t that what everybody here always critized at MacOS or
> Windows3.1/95 ?
> So the consequence is that a new AmigaOS must be redesigned
> in a big way which wouldn´t look like what you may have known
> from the old AmigaOS API.
> Maybe you should take a look at *realtime* systems under Yahoo
> and check out what they use basicly as their base API...they
> at least offer the basic Posix layer...sometimes also the multithread
> Posix layer compliance.
> If you don´t like these goals you have to search for the hardware
> and software which will satisfy you in the future.
Oh, get a grip. If we are to choose another existing OS instead of AmigaOS, a
Un*x variant would be about the best we can get, but if we are going to have
a new OS, it should not be a repeat of design mistakes from the past. Among
the glaring ones are
Un*x: Limited number of tasks and file descriptors, overly complex memory
management for backward compatiblity (e.g. mapping all proccesses from the
bottom of memory), limited task management, excessively hairy file/socket
descriptor API, monolithic design.
AmigaOS: Very limited support for adding memory protectionš, no API for MMU
utilisation, not enough RTG support, Forbid(), Disable().
Don't think OS design hasn't improved since Un*x was born. Backward
compatibility wishes just sometimes make it difficult or impossible to fix
design flaws.
__________
š And poor programming practice wrt. MEMF_PUBLIC makes backward compatibility
with such misprogrammed software impossible.
Regards,
/ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻTŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ\
| Rask Ingemann Lambertsen | E-mail: mailto:ra...@kampsax.dtu.dk |
| Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ |
| A4k/030, 16 MB, 3 GB, Ariadne | "ThrustMe" on XPilot, ARCnet and IRC |
| Copywight 1996 Elmer Fudd. All wights wesewved. |
phineas
Ralph Schmidt scribbled this on 6 Oct 1997 22:56:07 GMT:
> If you don´t like these goals you have to search for the hardware
> and software which will satisfy you in the future.
This really cheesed me off. I just noticed that after over 30 years
involved with computers I'm still as gullible as the first day.
Let me explain. Just over a year ago, someone in our local Fido echo
made the remark: "Phase 5 are a bunch of w*nkers." So I, believing in
the promised "Amiga-like" machine, went out of my way to defend phase5
and stated the proposed hardware features in defence of the A\BOX.
Just like the first Amiga, this was going to be something exciting.
Little did I know of this plot to sell us a unix box, where all this
hardware wizardry will be hidden from the programmer by layers of OS.
No more idle experimenting with software-hardware ideas that - to me -
was one of the Amiga's best features, no more revolutionary apps like
DPaint, Real3D, Imagine, LightWave, Bars&Pipes, OctaMED, ProTracker,
instead we're supposed to accept PDF, statistical programs, boring
scientific routines and multi-user capabilities as our daily fodder.
All useful, I'm sure, but I'm just a single-user who feels he has been
used and abused by false promises. If I wanted unix, I'd be reading a
different group, not comp.sys.amiga, and instead of waiting for the
A\BOX, I'd get a used Sun workstation right now...
There is also no need for listing "features" of unix vs. Amiga, I know
them and I still prefer the Amiga OS - unprotected mem, patches and
all, and as for a large software base, I'm quite happy with Aminet,
thankyou.
This is not a question of which OS is better - if I want to drive a VW
Camper, that's my decision until VW suddenly decided they won't build
them any more and told me I should get a Golf instead - in which case
I would just tell VW to go to hell...
So if it comes to choosing my software/hardware for the future, you
are forcing me into a very hard decision but it certainly won't be a
unix-box that's promised to be "Amiga-like". That's cheap hype.
> --
> Ralph Schmidt,la...@popmail.owl.de(private),NextMail welcome
> Phase5 ,la...@ufoo.phase5.de(work),NextMail welcome
One of your very cheesed off ex-defenders.
--
Bye,
:) _ //
_|hineas_AT_relicworld_DOT_demon_DOT_co_DOT_uk__Team AMIGA \X/
Colin Ward
Hans Guijt <hgu...@inter.nl.net> wrote:
>Colin Ward (co...@leprechaun.com.au) wrote:
>>decided to make it source compatible with AmigaDOS, and the one thing that
>>troubled me a lot was that the library system used by the Amiga seemed
>>*very* out of date... So I opted for the Windoze DLL style of loading &
>What you are really saying is that the way they are loaded is out of date,
>not the concept.
Exactly. Libraries are great! Just as long as they are not abused as
the are in Windoze. They should be used for stuff like reqtools.library
and playsid.libary - things that you can stick in your Libs: directory and
everyone can use. As long as things get like Windoze where everyone seems
to put half their code into libraries for *no* apparent reason, so you end
up with a million libraries on your system that don't get deleted when you
uninstall the program! Errrghh!
>>linking the libraries at load time. It's just silly to have to do an
>>explicit LoadLibrary() on each and every library that you need, checking
>>return codes, closing the libraries when you're done with them and
>>outputting error messages when you can't open them. It should all be done
>Amazingly, this _was_ a feature of AmigaOS, but nobody used it so it was
>removed in OS 2.0! Of course, modern Amiga compilers open libraries
>automatically.
Someone else in this thread said that it was in the documentation but not
actually implemented... But regardless, it's news to me, and interesting
news at that!
As for compilers opening libraries automatically, sure they open
intuition.library etc, but what about things like reqtools.library?
Someone once told me of SAS/C doing this automatically if it detected the
library base detected in your code but I've never been able to get it to
work...
Colin Ward
th...@math.tu-berlin.de (Thomas Richter) wrote:
>Hi Rudi!
>chia...@cli.di.unipi.it (Rudi Chiarito) writes:
>>Colin Ward (co...@leprechaun.com.au) wrote:
>>>by the OS... Have the library names embedded in the header of your
>>>executable so the OS loads 'em automatically and puts up a requester saying
>>>that it can't find/load one or more of 'em...
>>This was supported by AmigaDOS up to v1.3, but nobody (or almost nobody)
>>ever used the feature. IIRC it was also because LoadSeg() opened the libraries
>>without doing any version check (ie. it would open intuition.library whatever
>>version it was and the application would still need to check the version number
>>by itself and prompting the user in case of a library obsolete for the
>>program's needs).
>Well, let's say it in these terms: The documentation of 1.3 said it was
>supported, but, in fact, it never was. This implementation was PLANNED, though
>never done. The ADos manual used to be, and still is, a mess and completely
>unhelpful. (Sorry to say, but that's how it is...)
>Why do I know? Once when I was really bored, I made a doc about all BCPL
>routines in the 1.3 (v34) ADos and I really STEPPED THRU all routines,
>including the LoadSeg() (or, precisely, what is called InternalLoadSeg() today)
Well, implemented or not, it's certainly interesting news... Was it in
the old 1.3 autodocs that it was mentioned? I don't suppose you'd have the
old 1.3 dos.doc that you could snip it out of and post it would you? I'd
be interested to read that myself! I've only got the 3.0 autodocs...
Stefan Boberg
Jeroen T. Vermeulen wrote:
> I recall one description, from the ADE people I think, of a particularly
> hard-to-port UNIX program which could be reconfigured by starting it with a
> special option; it would then load any requested modules of itself into memory
> and *snapshot its own memory image to file*. Since the program "knows" that it
> will always run in the same environment, and the same environment will always
> load everything at the same address so no problem and never mind that relocation
> data. Good candidate for Horrible Kludge of the Century if you ask me.
AFAIK GCC has an option to this, to implement a sort of "precompiled
header" facility.
--
=====================================================================
Stefan Boberg
bob...@team17.com So many idiots, so few comets
Martin Recktenwald
Hans Guijt <hgu...@inter.nl.net> wrote:
> If you stick by your plans of making your boards incompatible to the H&P
> software, don't bother counting me as a customer or as a developer.
If they manage to base a new Amiga-like OS on top of a Unix kernel, they can
count on me.
Martin.
--
-------------------------------------------------------------------------
"Typically, revision numbering is used by organisations such as MicroSoft
to indicate how many bugs they have in their software. Microsoft Word
version 6 has 3 times as many bugs as Word version 2. Windows 95
therefore will have 32 times more bugs than Windows 3."
cvs Training Manual
-------------------------------------------------- mre...@cscip.uni-sb.de
Thomas Richter
Hi Ralph!
rba...@babylon.pfm-mainz.de (Ralph Babel) writes:
>Thomas Richter wrote:
/* snipped */
>> Well, let's say it in these terms: The documentation of
>> 1.3 said it was supported, but, in fact, it never was.
>> This implementation was PLANNED, though never done.
>No, Rudi is right: 1.x _did_ support resident libraries.
>The original Metacomco/Commodore linker was even able to
>create executables to take advantage of this. You'll find
>the details in section 22.2.9 of the Amiga Guru Book, which
>also includes a "hello, world" executable that makes use of
>LoadSeg()'s resident-library feature.
Oopsi! If it does support this stuff, it's well hidden below
in the secrets of InternalLoadSeg of the BCPL DOS v34. At least,
I haven't seen this routine....
Interesting that this is no longer supported, I guess it's
a quite practical feature, isn't it?
>> The ADos manual used to be, and still is, a mess and
>> completely unhelpful. (Sorry to say, but that's how it
>> is...)
>True. The Amiga Guru Book is still available from
>Ossowski, though: <URL:http://www.schatztruhe.de>.
(-; I'm currently collecting some freebee tickets for the
AmiNet CD, maybe the next time I order all this stuff...
(I've seen you promiting your book so often, that's what the grin is about)
Greetings,
Thomas
______________don't_cut_here,_it_could_damage_your_terminal____________________
_______ _____ _____
/ / / / / / / EMAIL: th...@einstein.math.tu-berlin.de
/ /____/ / / /____/ http://www.math.tu-berlin.de/~thor/thor/index.html
/ / / / / / \ PGP available on request, finger print:
/ / / /____/ / / 11 FC 46 B0 7F 42 43 AC 38 A4 78 9A 24 BC 77 BE
_______________________________________________________________________________
Kyzer
From the lips of Ralph Schmidt sprang:
: You must know more than us about an *official* AmigaOS ?
: And what tells you that when there´s an official new AmigaOS
: it wouldn´t go that route ?
: I think this route is what makes the most sense for a new
: AmigaOS. Basicly the same route would be taking a micro/pico Kernel.
: Write the whole IO/DRIVER/NETWORK layer yourself which is no
: trivial task(people and time) and basicly have the same in
: functionality you already get with the way i suggested.
What you're basically saying is:
- UNIX works. We can get the source of some unices.
Let's just use that instead. Will save time and money,
someone has done all the work for us.
- Computers will always get faster, it won't matter if
we stop worrying about performance issues.
- UNIXy or Windows, it's your choice. No other OS exists.
- We can make it good after we've finished selling it.
--
Stuart Kyzer Caie, Aberdeen University, Scotland. ...kyzer@4u.net...
My opinions are not those of Aberdeen University, and I do not speak for or
on behalf of AUCC. http://www.abdn.ac.uk/~u13sac/
--
Yesh I shee Felixsh, perhapsh I can be of shume ashishtanshe.
Kyzer
From the lips of Stefan Boberg sprang:
: Okay I'll bite: can you explain to me exactly WHY it is better to
: have shared libraries with jump tables rather than loader fix-ups?
I can think of one: loading won't fail if a library isn't there, or
in the wrong place, or the wrong version. You can give suitable error
messages as opposed to the one-size-fits-all System Message. Independance.
Actually, I can think of two. Library entry points can be patched in
realtime (although this can also be achieved with clever DLL writing)
--
Stuart Kyzer Caie, Aberdeen University, Scotland. ...kyzer@4u.net...
My opinions are not those of Aberdeen University, and I do not speak for or
on behalf of AUCC. http://www.abdn.ac.uk/~u13sac/
--
Sir, a transmission from zone 669881a - a transmission of priviledged code!
Ralph Schmidt
On 10/09/97, Kyzer wrote:
>From the lips of Ralph Schmidt sprang:
>: You must know more than us about an *official* AmigaOS ?
>: And what tells you that when there´s an official new AmigaOS
>: it wouldn´t go that route ?
>: I think this route is what makes the most sense for a new
>: AmigaOS. Basicly the same route would be taking a micro/pico
Kernel.
>: Write the whole IO/DRIVER/NETWORK layer yourself which is no
>: trivial task(people and time) and basicly have the same in
>: functionality you already get with the way i suggested.
>
>What you're basically saying is:
>
>- UNIX works. We can get the source of some unices.
> Let's just use that instead. Will save time and money,
> someone has done all the work for us.
For the driver and posix level..yes..the GUI and all the
API stuff is what you have to write.
>
>- Computers will always get faster, it won't matter if
> we stop worrying about performance issues.
>
How do you come to this conclusion from what i said in a whole ?
>- UNIXy or Windows, it's your choice. No other OS exists.
>
Oh well..if you wanna simplify it that way...it´s your choice.
If I had xyz millions in my pocket I could do this.
1) write a new OS in x years from scratch
2) move millions into the pockets of some big companies so
you get their support for basic stuff like web browser,
pdf,office packets or games
3) move millions into marketing so people buy this new stuff
or if you don´t have the money to generate a whole new SW
base **today**. It isn´t 1986 anymore.
1) Use some existing OS base(unix) so you have access to
all kinds of software and even commercial ports are easier.
Add some functionality stuff like more realtime task classes.
2) Concentrate on the things which are really important to the
user. The GUI and functionality.
And offer an API+functionality which attracts developer to
support this new middleware.
>- We can make it good after we've finished selling it.
>
How do you come to this conclusion from what i said in a whole ?
>--
>Stuart Kyzer Caie, Aberdeen University, Scotland.
...kyzer@4u.net...
>My opinions are not those of Aberdeen University, and I do not speak
for or
>on behalf of AUCC.
http://www.abdn.ac.uk/~u13sac/
>--
>Yesh I shee Felixsh, perhapsh I can be of shume ashishtanshe.
>
devu...@info.unicaen.fr
Stefan Boberg wrote:
>
> Jeroen T. Vermeulen wrote:
> > I recall one description, from the ADE people I think, of a
> > particularly hard-to-port UNIX program which could be reconfigured
> > by starting it with a special option; it would then load any
> > requested modules of itself into memory and *snapshot its own
> > memory image to file*. Since the program "knows" that it
> > will always run in the same environment, and the same environment
> > will always load everything at the same address so no problem and
> > never mind that relocation data. Good candidate for Horrible
> > Kludge of the Century if you ask me.
>
> AFAIK GCC has an option to this, to implement a sort of
> "precompiled header" facility.
Perl too! Quoted from "man perlrun":
-u causes Perl to dump core after compiling your script.
You can then take this core dump and turn it into an
executable file by using the undump program (not
supplied). This speeds startup at the expense of
some disk space (which you can minimize by stripping
the executable). (Still, a "hello world" executable
comes out to about 200K on my machine.) If you want
to execute a portion of your script before dumping,
use the dump() operator instead. Note: availability
of undump is platform specific and may not be
available for a specific port of Perl.
By the way, ELF is probably a good thing (because supported by the
industry), but what about the API to use ELF ppc-modules with
amiga-hunk 68k-modules mixed ? Will the programmer have to write
things like
PPCSegment = PPCLoadELF("progdir:ppc-objs/runtime-object1.o");
PPCTask = PPCAddTask(PPCSegment, stacksize);
in his/her code ? What about the portability on full-ppc machines or
68k only machines then ? The above scheme is thread-oriented.. so,
what about the portability with other thread-aware systems/projects ?
How to port non-thread oriented sources ? Will the programmer need
to redesign his/her software ?
Many interresting questions I guess.. but few answer seen on
this thread sofar.
sam.
--
-------------------------------------------------------------------
GREYC (UPRESA 6072) Université de CAEN F-14032 Caen CEDEX FRANCE
-------------------------------------------------------------------
e-mail: devu...@info.unicaen.fr
tel: +33 (0)2.31.56.53.19
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Stefan Boberg
Kyzer wrote:
> From the lips of Stefan Boberg sprang:
> : Okay I'll bite: can you explain to me exactly WHY it is better to
> : have shared libraries with jump tables rather than loader fix-ups?
>
> I can think of one: loading won't fail if a library isn't there, or
> in the wrong place, or the wrong version. You can give suitable error
> messages as opposed to the one-size-fits-all System Message.
You can still load libraries dynamically under Windows and Unix, if
you really want to. You just have to call them differently (a bit like
AmigaDOS, really).
Andreas Kleinert
Stefan Boberg (stefan...@team17.com) wrote:
: Okay I'll bite: can you explain to me exactly WHY it is better to
: have shared libraries with jump tables rather than loader fix-ups?
You can check the library's version number and provide replacement
code when being confronted with an older version, i.e. you can support
a wider range of OS versions without recompilation (and #compiler
switches).
--
ARK
Kyzer
Hurrah, for 'tis said that devu...@info.unicaen.fr did write:
: > AFAIK GCC has an option to this, to implement a sort of
: > "precompiled header" facility.
: Perl too! Quoted from "man perlrun":
: -u causes Perl to dump core after compiling your script.
For me at least, undumping never ever works. And debugging is best done
with the perl debugger rather than examining the coredump.
Use the perl compiler (experimental) if you want to precompile perl scripts,
--
Stuart Kyzer Caie, Aberdeen University, Scotland. ...kyzer@4u.net...
My opinions are not those of Aberdeen University, and I do not speak for or
on behalf of AUCC. http://www.abdn.ac.uk/~u13sac/
--
AtheistCode(v1.0) ACv1.0 DUR5 STR4 BIT4 ACT1 DEF4 DEB5 CON1 SLM5 XTN4 PUB2
Stefan Boberg
True enough, but how hard is it to compile a couple of different
executables with a bunch of #ifdef OS_VERSION >= 34 or somesuch?
Hannu Nevalainen
. .............
. ,--------:.Application.:
. ......v... /
. :.Amiga.OS.: /
. | /
. ...v............v.......
. :.Unix/Posix.MicroKernel.:
. |
. ...v......
. :.Hardware.:
As I understand Ralph Schmidt, the above is what he wants. To some extent at
least. This is acceptable to me. The "Posix Layer" will allow me to take a GNU
source archive, compile it, and have it run with little problems (compare with
geekgadgets/gcc/ixemul here - I see it as an extension of the same
possibilities).
I hope to be able to recompile any AmigaOS source code with ease. Not
necessarily with 100% "source compatibility", but something as close to it as
possible.
What I cannot see is why the Amiga shared libraries cannot be kept
_functionally_ equivalent to what they are today:
- Load on demand.
- Single code copy in memory.
- Multiple 'users' at any time.
- Unloaded when not used.
- Probably more to add here.
I'm not happy with the OS opening libraries that will be /in use/ for 1
second or less.
It is like having a file opened in the init section of a program just to
enable the program to write one line into it - after *10 hours* of computing -
thus locking out any other program that want to do the same. (I hope you see
the analogy to RAM usage here).
The library loading and unloading should stay /dynamic/ _during_ execution.
Whatever file format we have for executables should IMO be of no importance,
/for the user/. Ease of use for the _developer_ , debug capabilities,
other available possibilities, _transparent expandability_ and such _should be
taken into account_.
If there is a vast collection of tools already available for manipulating the
format, then that should be a very strong argument to use that particular
executable format.
The effect on how the user level of the software acts should IMO not be
affected by changing the program-storage on disk. (Will there be any
contradictions to this if we go ELF?)
/Hannu E K Nevalainen/ X == Remove before use
mailto:he...@warez.it.kth.se, http://www.ztrip.it.kth.se/~henk/
XXXXXX XXXXXX
The Amiga RC5 Team Effort homepage: http://www.cistron.nl/~ttavoly/rc5
--
Tag? Oh... the manager went for lunch, sorry!
Hans Guijt
Ralph Schmidt (la...@basis.owl.de) wrote:
>There´s no new AmigaOS. A port with the old AmigaOS base makes no
>sense and I don´t see a new AmigaOS at the horizon that offers
>MP,SMP,Resource Tracking, a posix layer and complete reworked API.
MP, SMP, resource tracking: difficult, but not impossible.
POSIX: it is hype. it is just a set of prescribed function calls.
Completely reworked API: just your opinion that we need it.
Amiga, Inc. is quickly building a development team. Of course you've been
hacking UNIX pretty heavily lately so you may not have kept up with
developments, but new AmigaOSes have been announced.
>I also don´t see how some small Amiga company should be able to
>produce all the PCI drivers people seem to demand when they asked
>for a PCI bus and the cheap expansion cards.
I think the resources of Amiga, Inc. are quite a bit better than those of
Phase5. And since we don't have a PCI bus right now I don't think we need
those PCI drivers you talk about all the time. Or is there a PCI bus on the
PowerUp card?
>All this would come with a microkernel and a Unix Server
Yes, but we loose everything else! It's like we always had raw meat and
asked for our meat to be cooked, and we are given cooked potatoes instead!
>Do you seriously expect that anybody today can afford to put HW
>informations open and let the coder hack it to death until the HW
>development is dead due to compatibility issues like with the Amiga
>chipset ?
Since WarpOS qualifies as a KERNEL and therefore an alternate OS I think it
is quite unreasonable to force them to work through your OS. It would be
like forcing Linux to run through Windows - undesirable. Especially since
H&P did some pretty good work, like fast context switches (0.5 msecs instead
of 60-90 msecs, that's a hell of a lot of difference!) which would of course
be impossible when running on top of your kernel.
>AAA wasn´t AA compatible either.
AAA wasn't, period.
>What do you think have these programs besides these trackers to do
>with direct HW poking ? And doesn´t delitracker show that MOD players
>work fine with a device ?
Again, your arrogance surprises me. How can you know ahead of time what all
those machines will be used for? How can you even hope to make your system
meet everyones needs? And how can you be sure that Phase5s kernel will
enforce good programming? I'm sure I can _easily_ program something that
breaks _every_ forthcoming version of the Phase5 software if I wanted to.
Your arguments for a bondage-and-discipline OS simply don't hold.
>We want a MicroKernel with a Unix layer which saves us a lot develop
>time, money and also gives us a software base AND THEN put on this
>base an own OS(middleware) which has nothing to do with X11.
Great news, but what software will you run that doesn't require X? Not
everyone likes commandlines you know... Without X you are loosing a very
significant part of the (limited) UNIX software market.
UNIX has lots of software, sure: development tools, more development tools,
lots of stuff to do system administration, etc. It may not have occurred to
you, but most users demand slightly more of their computer. Word processors,
that kind of thing.
>And a lot Amiga users and the *market* demands these things you
>deny.
No, Amiga users took AmigaOS so much for granted that they forgot to demand
it too. We want MP, SMP, RT, RTG, etc. but NOT if it excludes the OS we love.
>Look. I understand your point. You wanna keep what you know until
>judgement day but that won´t happen and you will also get less
>software. What do you think will happen if the current AmigaOS
>design would be ported to a different architecure ?
We would port software to it, that's what. We would be happy with the
extreme effiency of AmigaOS and its general usefulnes, logical structure and
operation, power, and userfriendliness. We wouldn't spend every day moaning
that we had something great and gave it up to become part of the UNIX crowd.
If Phase5 allows that (ie. allows us to have AmigaOS through the guise of
WarpOS or something) then all this discussion is futile. I don't mind if you
port Linux to the Amiga, I just don't want it to be the only option.
Why is that so impossible? Why does Phase5 need to act like a Microsoftian
dictator?
>A few thousand Amiga owners would probably buy this and then
>a small part of these will do some software. The market wouldn´t
>increase and it wouldn´t attract new developers which the Amiga
>market seriously needs.
Negativism buys you nothing. A UNIX box that is incompatible to normal UNIX
will get even fewer developers.
We have a few developers left. These can easily port existing Amiga source
to PowerUp, assuming it is running an AmigaOS-like system. From there things
will have to grow. Phase5 *must* make a deal with Amiga, Inc to ensure
compatibility between their PowerUp boards and future Amigas, or all your
development will be wasted money.
Only when new Amigas are sold that have enough CPU power can you attract new
developers. The OS these machines run will be relatively unimportant for
those - they will be porting from Windows and Apple mostly. Having an
attractive OS that ENABLES instead of DISABLES will be a great benefit. Many
developers LIKE to program for the Amiga as a system! It is
market-circumstances that have forced them away, not OS-related problems.
>Take a look at NextStep and tell me if you see so much *unix*. You
Take another look at NextStep and tell me if you see any *market*.
Hans
Tor-Einar Jarnbjo
On 08-Okt-97 23:26:38, Rask Ingemann Lambertsen wrote in comp.sys.amiga.programmer:
>On 07-Okt-97 10:47:03, Ralph Schmidt wrote the following about "Re: WarpUP vs
>ppc.library test!":
>[cut a lot]
>> And by the way...it愀 not a Unix clone...not from you and a lot
>> people understand by Unix. You and a lot people seem to think
>> Unix means X11 UserInterface and weird APIs.
>Unix _does_ mean weird APIs. Once you leave it the "Hello world" level, you
>run into it pretty quickly. It is the result of feeping creaturism. Try
>comparing e.g. the BSD socket interface with ANDI (Holger Kruse's proposed
>Aminet networking API), for even such a simple thing as opening a connection
>to a remote host. Then try nonblocking sockets and it becomes a nightmare on
>Unix.
I've programmed some stuff using the BSD socket.lib, and also with non-
blocking sockets. And, it wasn't any particulary difficult AFAIR.
Tor-Einar
Kyzer
From the lips of Stefan Boberg sprang:
: > From the lips of Stefan Boberg sprang:
: > : have shared libraries with jump tables rather than loader fix-ups?
: > I can think of one: loading won't fail if a library isn't there, or
: > in the wrong place, or the wrong version. You can give suitable error
: > messages as opposed to the one-size-fits-all System Message.
: You can still load libraries dynamically under Windows and Unix, if
: you really want to. You just have to call them differently (a bit like
: AmigaDOS, really).
You can also open libraries when you need them. For example, a program
could work on files from the cli, or if asked to, open a GUI. It therefore
has to call out to a nice large GUI library, for argument's sake, let's
say it's something inhibitingly large like MUI or libX11.
Now, it has to make reference to the library to use it, but it doesn't
have to use this GUI library unless it opens a GUI. If the user only
wants to process from the command line, why should the exe loader open
up a GUI library into the system?
I suppose you'd demand we write seperate GUI and cli versions, even though
they otherwise use the same code. The seperate binaries taking up precious
disk space. (But of course, computers get faster and disk gets larger.
No need to do anything about redundancy just yet.)
--
Stuart Kyzer Caie, Aberdeen University, Scotland. ...kyzer@4u.net...
My opinions are not those of Aberdeen University, and I do not speak for or
on behalf of AUCC. http://www.abdn.ac.uk/~u13sac/
--
$a=0;foreach(`df -k`){$a+=(split/\s+/)[1];}printf"%.2fMB mounted\n",$a/1024;
Hans Guijt
Stefan Boberg (stefan...@team17.com) wrote:
>> Amazingly, this _was_ a feature of AmigaOS, but nobody used it so it was
>> removed in OS 2.0! Of course, modern Amiga compilers open libraries
>> automatically.
> Okay I'll bite: can you explain to me exactly WHY it is better to
>have shared libraries with jump tables rather than loader fix-ups?
Of the top of my head:
* To maintain conceptual coherency (if you don't you will end up with a
system that is full of 'patches and cludges').
* Because fixing addresses while loading is just another kludge that was
necessary because real libraries were never part of the UNIX system - they
adopted it quite recently because it had proven to be bloody useful on
systems like the Amiga.
* To maintain compatibility with current systems (OS, compilers, etc.).
* Because it allows runtime patching.
* Because the jumptable is really a virtual function table, and libraries
really are objects. That means eg. that from an OS pov. all devices are the
same. Imagine the kludges you would have to apply to build a similar system
using ELF-style libraries! The same goes for datatypes, and basically
anything that uses interchangable libraries that have similar interfaces
(the XFH system, for instance).
Hans
Stefan Boberg
Kyzer wrote:
> From the lips of Stefan Boberg sprang:
> : Kyzer wrote:
> : > From the lips of Stefan Boberg sprang:
> : > : have shared libraries with jump tables rather than loader fix-ups?
> : > I can think of one: loading won't fail if a library isn't there, or
> : > in the wrong place, or the wrong version. You can give suitable error
> : > messages as opposed to the one-size-fits-all System Message.
>
> : You can still load libraries dynamically under Windows and Unix, if
> : you really want to. You just have to call them differently (a bit like
> : AmigaDOS, really).
>
> You can also open libraries when you need them. For example, a program
> could work on files from the cli, or if asked to, open a GUI. It therefore
> has to call out to a nice large GUI library, for argument's sake, let's
> say it's something inhibitingly large like MUI or libX11.
You can already do this. In Windows, there's a function call
equivalent to LoadLibrary().
Stefan Boberg
> > Okay I'll bite: can you explain to me exactly WHY it is better to
> >have shared libraries with jump tables rather than loader fix-ups?
>
> Of the top of my head:
>
> * To maintain conceptual coherency (if you don't you will end up with a
> system that is full of 'patches and cludges').
Could you expand on this? It doesn't make any sense to me.
> * Because fixing addresses while loading is just another kludge that was
> necessary because real libraries were never part of the UNIX system - they
> adopted it quite recently because it had proven to be bloody useful on
> systems like the Amiga.
Fixing addresses while loading is already performed by AmigaDOS and I
don't see how patching a call to a shared library is different from
patching a call to a different code segment.
> * To maintain compatibility with current systems (OS, compilers, etc.).
I thought this whole discussion was due to the switch to PPC, and it
hardly matters then does it? Besides, you could easily have it both
ways. Let me show you how: [I don't know PPC asm so please forgive my
pseudo-code]
SECTION kludgeLibrary
jumpTable: jmp Func1
jmp Func2
jmp Func3
jmp sysFunc1
jmp sysFunc2
jmp sysFunc3
jmp sysFunc4
libraryBase: .bss LIBRARY_BASE_SIZE
This section could be included in the ELF DLL, and any app would then
be able to load and use libs by the old calling mechanism (by providing
a special LoadLibrary() call, which BTW would be *very* simple to
implement). I doubt anyone would want to, but hey ...
> * Because it allows runtime patching.
That could still be performed. Not that it should be necessary or
allowed, but anyway...
> * Because the jumptable is really a virtual function table, and libraries
> really are objects. That means eg. that from an OS pov. all devices are the
> same. Imagine the kludges you would have to apply to build a similar system
> using ELF-style libraries! The same goes for datatypes, and basically
> anything that uses interchangable libraries that have similar interfaces
> (the XFH system, for instance).
No kludges are required. Or are you saying that the COM interface in
Windows doesn't work? It provides dynamically loaded objects, and it
works very well for me ... I'd be interested in hearing what problems
this approach cases, in your expert opinion.
Michael Krause
On 9 Oct 1997, Hannu Nevalainen wrote:
> It is like having a file opened in the init section of a program just to
> enable the program to write one line into it - after *10 hours* of computing -
> thus locking out any other program that want to do the same. (I hope you see
> the analogy to RAM usage here).
> The library loading and unloading should stay /dynamic/ _during_ execution.
Unix-style shared libraries are even more dynamic than the Amiga
shared libraries. Only the *used* code is loaded into memory. On the
Amiga, the whole muimaster.library (just an example, because it's so
big) is loaded when a MUI program starts up; Unices just set up the
memory map accordingly but don't load any actual data from the disk.
When the CPU first hits a location in that library, that page (1K)
will be loaded into memory. This way, a library (and this mechanism is
also extended to the executable itself) is not explicitly loaded, but
rather implicitly page-faulted into memory, when the CPU reaches new
pages while running. You definitely need an MMU for this to work ;)
It would be off-topic to elaborate on this, but have a look at "The
Design of the UNIX Operating System" by Maurice J. Bach, if you're
interested. Or play around with Linux, that's the way I got to know
this architecture. Actually, the book is quite boring if you've read
the Linux sources ;D
off-topic off-topic off-topic...
bye,
michael krause aka raw style/lego^elke (amiga & linux)
http://ms.demo.org/rst/ --join mekka & symposium 1998!
Michael Krause
On 9 Oct 1997, Hans Guijt wrote:
> Ralph Schmidt (la...@basis.owl.de) wrote:
> >There=B4s no new AmigaOS. A port with the old AmigaOS base makes no
> >sense and I don=B4t see a new AmigaOS at the horizon that offers
> >MP,SMP,Resource Tracking, a posix layer and complete reworked API.
>=20
> MP, SMP, resource tracking: difficult, but not impossible.
Impossible, not difficult. Well, Hans, I respect you defending the
Amiga spirit, but exactly that statement is very very wrong. Resource
tracking could be the only thing that I wouldn't consider really
impossible, but without proper MP this just isn't fun.
Why no MP? Have a look at how PutMsg() works. But don't tell anyone.
> POSIX: it is hype. it is just a set of prescribed function calls.
Hmm, one can argue about that. Yes, it's quite a bit incoherent, but
so is a BCPL DOS in a C Exec environment...
> Amiga, Inc. is quickly building a development team. Of course you've been
> hacking UNIX pretty heavily lately so you may not have kept up with
> developments, but new AmigaOSes have been announced.
There was that time when I used to believe that, too. See, I find it
really funny when now and then, in a discussion about features not
found on Amiga but on other ("more advanced") platforms, I read
sentences like "But with the new hyper cool DX-Super-Flash Gfx Card
PPC Gadget whatever, everything will become better, Amiga rulez
4eva!!!!" Get the point?
> I think the resources of Amiga, Inc. are quite a bit better than those of
> Phase5.
Which resources? In the last few years they have proven they don't
have any, IMHO.
> >What do you think have these programs besides these trackers to do
> >with direct HW poking ? And doesn=B4t delitracker show that MOD players
> >work fine with a device ?
Uhhh, ohh, Ralph, sorry that I have to disappoint you... DeliTracker
bangs the Hardware as well ;))
=2E..ah yes, just one thing, guys: Don't start flaming me for talking
bad about your beloved Amiga; If I didn't like anything about that
machine any more, I wouldn't read this NG...
Samuel Devulder
Stefan Boberg wrote:
>
> Jeroen T. Vermeulen wrote:
> > I recall one description, from the ADE people I think, of a particularly
> > hard-to-port UNIX program which could be reconfigured by starting it with a
> > special option; it would then load any requested modules of itself into memory
> > and *snapshot its own memory image to file*. Since the program "knows" that it
> > will always run in the same environment, and the same environment will always
> > load everything at the same address so no problem and never mind that relocation
> > data. Good candidate for Horrible Kludge of the Century if you ask me.
>
> header" facility.
Perl too! Quoted from "man perlrun":
-u causes Perl to dump core after compiling your script.
You can then take this core dump and turn it into an
executable file by using the undump program (not
supplied). This speeds startup at the expense of
some disk space (which you can minimize by stripping
the executable). (Still, a "hello world" executable
comes out to about 200K on my machine.) If you want
to execute a portion of your script before dumping,
use the dump() operator instead. Note: availability
of undump is platform specific and may not be
available for a specific port of Perl.
By the way, ELF is probably a good thing (because supported by the
industry),
but what about the API to use ELF ppc-modules with amiga-hunk
68k-modules
mixed ? Will the programmer have to write things like
PPCSegment = PPCLoadELF("progdir:ppc-objs/runtime-object1.o");
PPCTask = PPCAddTask(PPCSegment, stacksize);
in his/her code ? What about the portability on full-ppc machines or
68k only machines then ? The above scheme is thread-oriented.. so,
what about the portability with other thread-aware systems/projects ?
How to port non-thread oriented sources ? Will the programmer need
to redesign his/her software ?
Many interresting questions I guess.. but few answer seen on
this thread sofar.
--
Samuel Devulder
sam.
Samuel Devulder
Samuel Devulder
Peter McGavin
Stefan Boberg <stefan...@team17.com> writes:
>Hans Guijt wrote:
>> Amazingly, this _was_ a feature of AmigaOS, but nobody used it so it was
>> removed in OS 2.0! Of course, modern Amiga compilers open libraries
>> automatically.
>
>have shared libraries with jump tables rather than loader fix-ups?
Perhaps it's not what you had in mind, but there are several
advantages of OpenLibrary() over static loading, for examples:
A program can save memory by opening a library only if/when it needs
it and closing it immediately afterwards. A static loader keeps all
libraries open, probably wasting memory, the whole time the program is
running.
The same technique allows a program to run if a library is missing and
the code requiring the library is never called. A static loader
requires all libraries present at load-time.
A program can behave differently depending on whether a library opens
successfully. For example, a game could enable network options only
if socket.library opens successfully, or a paint program could enable
CyberGraphX support if cybergraphics.library opens successfully. A
static loader fails to load the program if a library is missing.
A program can define (or use) a standard library interface and
dynamically load a user-specified library, device driver or module
(implemented as a library) which conforms to that interface. For
example, a graphics package might have dozens of device drivers for
different kinds of printers, plotters and displays, all conforming to
the same library interface. Then the program loads just the one(s)
selected by the user at run-time. A static loader would load all the
drivers at once, or they would be all linked into the program. That
would waste resources and complicate the addition or modification of
drivers.
--
Peter McGavin. (p.mc...@irl.cri.nz)
Andreas Kleinert
Hannu Nevalainen (he...@warez.it.kth.se) wrote:
: . .............
: . ,--------:.Application.:
: . ......v... /
: . :.Amiga.OS.: /
: . | /
: . ...v............v.......
: . :.Unix/Posix.MicroKernel.:
: . |
: . ...v......
: . :.Hardware.:
: As I understand Ralph Schmidt, the above is what he wants. To some extent at
Is it ? Ralph ? (And sepaking for Phase5 ?)
--
ARK
Andreas Kleinert
Stefan Boberg (stefan...@team17.com) wrote:
: True enough, but how hard is it to compile a couple of different
: executables with a bunch of #ifdef OS_VERSION >= 34 or somesuch?
Not #ifdefs, just run-time-ifs like the following
if(LibVer(ExecBase) > 39)
{
}else
{
}
Where LibVer() is the following macro:
#define LibVer(x) ( ((struct Library *) x)->lib_Version )
--
ARK
Andreas Kleinert
Kyzer (junk...@sysa.abdn.ac.uk) wrote:
: You can also open libraries when you need them. For example, a program
: could work on files from the cli, or if asked to, open a GUI. It therefore
: has to call out to a nice large GUI library, for argument's sake, let's
: say it's something inhibitingly large like MUI or libX11.
Right. Dynamically opening/closing/expunging libraries during runtime
is another valid point.
--
ARK
Andreas Kleinert
Stefan Boberg (stefan...@team17.com) wrote:
: You can already do this. In Windows, there's a function call
: equivalent to LoadLibrary().
Possibly. But the thread is about ELF and not .EXE/.OBJ
--
ARK
Nicholas Stallard
Stefan Boberg (stefan...@team17.com) had the following to say about "Re: WarpUP vs ppc.library test!"
> Hans Guijt wrote:
>> Amazingly, this _was_ a feature of AmigaOS, but nobody used it so it was
>> removed in OS 2.0! Of course, modern Amiga compilers open libraries
>> automatically.
> Okay I'll bite: can you explain to me exactly WHY it is better to
> have shared libraries with jump tables rather than loader fix-ups?
Old bad habit ? :-)
Cya,
Nicholas
--
__
__/// Sn...@studbox.uni-stuttgart.de <*> Yag...@irc.undernet.amigacafe
\XX/ http://home.pages.de/~Snowy/ <*> No questions, No Lies. -Gaff
Rudi Chiarito
Stefan Boberg (stefan...@team17.com) wrote:
>two or three different versions of your code instead. Or -- if you're so
>bothered about it you can actually write a wrapper that will enquire the
>DLL about the availability of a given function (rather than explicitly
>checking a version number). This is all possible and MORE flexible than
Or each library could provide a libversion() function which returns the
version number.
Still I prefer Exec libraries though :)
--
Sometimes you make me feel like I am living at the edge of the world
"It's just the way I smile", you said
Rudi Chiarito - Magrathea & SushiWare Development - Jay Miner Society Member
EMail: chia...@cli.di.unipi.it - WWW: http://www.cli.di.unipi.it/~chiarito/
MISTAKES/MISSPELLINGS ARE FICTIONAL: A SIMILARITY TO REAL ONES IS INCIDENTAL
Stefan Boberg
Peter McGavin wrote:
> Stefan Boberg <stefan...@team17.com> writes:
> > Okay I'll bite: can you explain to me exactly WHY it is better to
> >have shared libraries with jump tables rather than loader fix-ups?
>
> Perhaps it's not what you had in mind, but there are several
> advantages of OpenLibrary() over static loading, for examples:
>
> A program can save memory by opening a library only if/when it needs
> it and closing it immediately afterwards. A static loader keeps all
> libraries open, probably wasting memory, the whole time the program is
> running.
>
< <...more examples deleted...>
Yes, but you can do all this AND have automatic loading with ELF-style
DLL's.
Stefan Boberg
Andreas Kleinert wrote:
> Stefan Boberg (stefan...@team17.com) wrote:
>
> : True enough, but how hard is it to compile a couple of different
> : executables with a bunch of #ifdef OS_VERSION >= 34 or somesuch?
>
> Not #ifdefs, just run-time-ifs like the following
>
> if(LibVer(ExecBase) > 39)
> {
> }else
> {
> }
No, really! I've never seen such code in my life! Wow. This is a
revelation :|
I DO know a bit about programming the Amiga, and I was saying that
instead of the above code, it's not that much more difficult to compile
two or three different versions of your code instead. Or -- if you're so
bothered about it you can actually write a wrapper that will enquire the
DLL about the availability of a given function (rather than explicitly
checking a version number). This is all possible and MORE flexible than
the current Amiga library system.
Carl Skedinger
Rask Ingemann Lambertsen wrote:
>
> On 07-Okt-97 01:25:32, Ben Hutchings wrote the following about "Re: WarpUP vs ppc.library test!":
> > You do not need to run UNIX to be able to run X11. eXceed, AmiWin,
> > GfxBase's X server and the X server from ADE prove this.
>
> As does the countless of X11 server implementations for Windos, Mac,
> dedicated X terminals and God knows what else. X11 _is_ it's own gfx system,
> and X11 problems are X11 problems no matter what you run X11 on.
What are those 'X11 problems'?
/Calle
--
------------------------------------------------------------------------
Calle Skedinger e92...@e.kth.se