Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: whoosh777 on April 04, 2004, 04:02:28 PM
-
here is an idea I have been thinking about for some time,
reading Fabio's comments in the OS4 vs MOS vs AROS thread it
sounds like this hasnt been done,
this idea will probably depress people of several other projects
but it could be a sound way to secure the Amiga's future,
step 1. Port AROS to 68k AGA!
why on earth do that? :read on,
Let me explain, 2 projects bypass all known issues:
1. AROS: this bypasses accusations of stolen source because its
open source. Hyperion by using AROS also give it their
stamp of approval,
2. UAE: The A1 itself uses this, thus it is officially endorsed!
Now the problem with UAE is that it requires ROM ownership,
thus fantastic though it is: I have been told that WinUAE
gives disk speeds of 58Meg/second and it has truecolour etc,
it has the problem that its market cannot grow except through ROM piracy,
at least not without Amiga co.'s approval,
And the problem with AROS according to Fabios comments is it cannot
run 68k binaries, that was never the projects intention,
So my way around all this is that if AROS is ported to 68k AGA,
that will then furnish an opensource Kickstart ROM for UAE!
I dont know much about UAE but it sounds like it emulates AGA custom chips
and 68k CPU but requires a 68k AGA OS ROM binary to be complete:
enter a very specific almost absurd port of AROS to provide
an opensource freely distributable reimplemented 68k AGA OS3.1 ROM binary,
This way 68k AROS AGA will create open source OS3.1 for all systems,
and the market can then grow, very fast because its for free,
and it will run on all known hardware: Mac, PC, Linux, Unix, A1, Pegasos,
and all existing 68k binaries will run on it,
who needs OS4 if you can do this?
68k AGA code can then be used as virtual machine code,
which means you can have closed source cross platform binaries:
so no need for Amiga DE which also tries this but appears to use
an undocumented binary format and requires a license fee or something,
this means that people can create closed source commercial programs,
IMO for a platform to take off you really need to be able to have
closed source commercial programs,
The Amiga co. can also make money by selling eg OS3.9 to run atop this,
-
And the problem with AROS according to Fabios comments is it cannot run 68k binaries, that was never the projects intention,
No, wait, that's not what I said, I said that AROS' aim has never been to run 68k binaries on other CPU's than 68k's, which is quite different...
-
AGA? Why AGA? This is hardware dependent and has no future.
-
whoosh777 wrote:
68k AGA code can then be used as virtual machine code
Speculation on my part, since I'm no hardware/HAL guru, but no matter how fast you run the emulation, it's going to be held back by the architecture - addressing modes, registers, etc - that the emulated processor offers. And you can't change them, or you'll break compatibility.
Using AGA emulation in the way you describe is also... well, insane, quite frankly. Why toss the Amiga's established RTG system out of the window?
:-?
-
AGA has had its day, and that day was some 10 years ago. Its only good for ye hardware banging 2D games of yore.
UAE has to devote considerable CPU resources to emulate AGA at full speed (which is tragic considering how slow that definition full speed is in modern terms), the *sole* benefit of which is running various aga based programs.
All serious amiga software of the last decade or so years has been RTG friendly.
Casting that aside, you have this notion of UAE as an "OS", running unhosted on your PC that gives transparent 680x0 emulation.
I'm afraid it's already been done. Amithlon was pretty much just that.
I could be wrong, but it still needs OS ROMs to work.
A replacememnt ROM for Amithlon (and a general update of the whole thing wouldnt hurt) based on open source code would pretty much do the job you are asking, AGA emulation aside.
As for how useful it would prove to be, I can't say.
-
whoosh777 has raised a good point, and that point is that the Amiga Port of aROS is seriously lacking.
From what I can see the biggest issue here is bootsrapping the Amiga before the OS comes into play... if any Demos coders out there want to have some fun again.. they could do worse than get AROS booting on the Amiga... We already have the 68k dependant code runnign on the palm... come on guys, we need you :-D
-
by falemagn on 2004/4/4 16:12:33
Quote:
And the problem with AROS according to Fabios comments is it cannot run 68k binaries, that was never the projects intention,
No, wait, that's not what I said, I said that AROS' aim has never been
to run 68k binaries on other CPU's than 68k's, which is quite different...
-----------------------------------
seems I wasnt reading carefully enough,
whats the thinking behind this?
if AROS were to run a 68k binary such as SAS C 6.50 on an Intel machine,
what issue is it that you want to avoid?
Eyetech by using UAE endorse AmigaOS being run on any CPU provided an
official ROM is used,
Hyperion by using AROS code endorse open source reimplementations,
so combining these 2 endorsements we get that
UAE can be used on an open source reimplemented ROM?
-----------------------------------------
@KennyR
AGA? Why AGA? This is hardware dependent and has no future.
-----------------------------------------
really I meant the entire custom chipset, just for compatibility reasons,
interleaved bitmaps are a slow and obsolete concept,
new programs for a new OS shouldnt reference the chipset at all,
probably a good idea to read + write protect the chipset via MMU
for new programs to prevent the chipset being used,
-----------------------------------------------------------------------
@that_punk_guy
>Speculation on my part, since I'm no hardware/HAL guru, but no matter
>how fast you run the emulation,
>it's going to be held back by the architecture - addressing modes, registers, etc
> - that the emulated processor offers. And you can't change them, or you'n
>l break compatibility.
yes, but JIT emulation is pretty fast: Morphos people say theirs is 75% of
native speed,
really its only when you reach a slowdown of 400% that you should start worrying,
if you upgrade your computer to one which is 2 x as fast its quite a disappointment,
when its 8 x as fast then its impressive, IMO 4 x is the cut off point to be
impressed,
also you dont need that many registers, good compilers convert local variables
to registers on a many-to-many basis, you only need maybe 8 or even 4
general purpose registers,
in fact you could get very fast code without any registers due to the
fact that the currently executing functions stack slot will usually
entirely be in the cache, probably in the L1-cache,
the preoccupation with having lots of registers is a hangover from
the days when everyone coded in assembler,
also 3-address code eg "add d0,d1,d2" (d2 = d0 + d1 ) is also
of dubious merit, Motorola 68k uses 2-address code "add d0,d1" (d1=d1 + d0),
in fact 1-address code "add d0" (accumulator = accumulator + d0) is probably
just as good,
probably even 0-address code "add" (pop pop add push) is also just as fast,
one problem with 3-address code is that you end up with huge instructions
(eg 1 instruction = 32 bits: twice as big as typical 68k instructions),
with 0-address code you could fit 8 instructions in that space,
anyway the point I am making is that 68k's 2-address code with 8 to 16
registers is probably just as good and twice as small as PPC's 3-address code
with 32 registers: most of those 32 registers will be asleep most of the time,
example:
x = y * z + t ;
in 3 address code:
lea y,d2
load 0(d2),d0
lea z,d2
load 0(d2),d1
mul d0,d1,d1
lea t,d2
load 0(d2),d0
add d0,d1,d1
lea x,d2
store d1,0(d2)
(RISC code is like wearing a strait-jacket),
1 address version:
load y ; to accumulator
move d0 ; from accumulator
load z ; to accumulator
mul d0 ; accumulator = accumulator * d0
move d0
load t
add d0
store x
1 address code is actually much more in the spirit of the RISC concept,
Motorola 68k version:
move.l z,d1
muls.l y,d1
add.l t,d1
move.l d1,x
0 address code version:
push y
push z
mul
push t
add
pop x
:clean + simple,
the 1-address version certainly outdoes the 3-address version on all
counts: smaller + shorter + fewer instructions, fewer overall memory references,
the real gain of having eg 1-address code with eg 4 registers is
you end up with a huge reduction in chip circuitry
=> much smaller => much faster,
>Using AGA emulation in the way you describe is also... well, insane,
> quite frankly. Why toss the Amiga's established RTG system out of the window?
I agree, I'm not stopping you using the RTG system,
I am just thinking of the classic AGA machine as a bootstrap OS,
you can have all the modern stuff you want atop that bootstrap OS,
so eg you can and should have the RTG system,
doing everything via 68k means you eliminate the need for
open source + recompilation,
:it will save centuries of effort and eliminate truckloads of bloat!
open source always becomes very bloated
eg the general trend is for source code that exceeds 9meg compressed,
regardless of what it does, IMO a lot of it is
"tactical" bloat
manufacturing industry is totally closed source,
visit http://ftp.gnu.org/gnu to see what open source really looks like,
now visit http://www.aminet.net to see what closed source looks like,
which do you prefer?
I dont know about you but I only use open source stuff out of necessity,
I much prefer eg SAS C 650 to gcc, but some things can only be done via gcc,
gcc also has some really neat features eg it will convert c to assembler,
---------------------------------------------------
@Karlos
>UAE has to devote considerable CPU resources to emulate AGA at full speed
>(which is tragic considering how slow that definition full
>speed is in modern terms), the *sole* benefit of which is running
>various aga based programs.
but the AGA emulation will only happen if you make AGA calls,
so if you run a modern 68k program that makes no use of the custom chips
then that overhead vanishes,
>All serious amiga software of the last decade or so years has been RTG friendly.
I am not stopping you having RTG,
I am all for modern ways of doing things,
but whichever way you do it I think you need OS3.1 68k compatibility,
and you also want the market to grow. Probably also the Amiga OS has to
tear itself away from the central company and become a 3rd party OS,
all the really interesting developements have come from the 3rd party,
as far as I can see there is no disciplic continuity from the original
Amiga OS creators to Hyperion and they have delivered *nothing*,
ie I think they have no mandate
>Casting that aside, you have this notion of UAE as an "OS", running
>unhosted on your PC that gives transparent 680x0 emulation.
>
>I'm afraid it's already been done. Amithlon was pretty much just that.
>
>I could be wrong, but it still needs OS ROMs to work.
but Amithlon has been derailed by legal issues, also doesnt it need a
ROM to function?
I'm not against AROS reimplemented ROM to use with Amithlon,
same idea,
someone told me Amithlon itself makes use of UAE,
it would also be sensible to try and bring Amithlon to other CPUs such as PPC,
>A replacememnt ROM for Amithlon (and a general update of the whole thing
>wouldnt hurt) based on open source code would pretty much do the job
> you are asking, AGA emulation aside.
I am equally happy with this pathway, I dont know what is the issue
thats stopping Amithlon
>As for how useful it would prove to be, I can't say.
an emulator + a reimplemented ROM may be the only way for the
platform to continue,
IMO the only sensible path for OS4 would be to
use a 68k emulator + OS3.1 ROM binary for backwards compatibility,
you should be able to directly boot OS3.1 on an A1
after about 1 year since the OS4 project begun,
if reimplementing OS3.1 native is nowhere near complete after 1 year,
the project should be shelved and an emulated version worked on,
once a directly booting OS3.1 is available and for sale then
they can work on reimplementing it properly,
but you need to have some product out there and on the shelves,
and on peoples desks,
OS4 shouldnt even be thought about till OS3.1 is complete and
for sale: either emulated or "ported",
people complain about H & P but at least they delivered OS3.9
which I use every day,
Hyperion havent delivered anything at all,
they know how to grab the OS contract and never ever let go
but not how to deliver the product, not even a bad product,
--------------------------
@bloodline
From what I can see the biggest issue here is bootsrapping the Amiga
before the OS comes into play... if any Demos coders out there want to
have some fun again.. they could do worse than get AROS booting on the Amiga...
--------------------------
if they can get AROS directly booting from an A1 that will be a major
achievement,
will they also need to port gcc to that specific setup?
I would still like the ability to run my 68k programs,
maybe if they can port UAE to run above that version of AROS,
I dont know what the issues are in porting UAE,
-
Whoosh777 was the sound of this going over my head.
Are you deliberately trying to confuse us?..... :smack:
Of course that could just be me. :-?
-
@bloodline
From what I can see the biggest issue here is bootsrapping the Amiga
before the OS comes into play... if any Demos coders out there want to
have some fun again.. they could do worse than get AROS booting on the Amiga...
--------------------------
if they can get AROS directly booting from an A1 that will be a major
achievement,
will they also need to port gcc to that specific setup?
I would still like the ability to run my 68k programs,
maybe if they can port UAE to run above that version of AROS,
I dont know what the issues are in porting UAE,
Booting an A1 with AROS is not that hard, since the A1 has it's own firmware (The UBoot BIOS) to bootstrap the hardware... bootstraping a real Amiga is much harder since AROS would have to do that itself.. the real Amiga's OS and firmware are one and the same.
UAE runs fine on AROS, but some people would like to see it be able to pass OS function calls from the Emulation through to the Main AROS OS thus integrating it.
-
bloodline wrote:
UAE runs fine on AROS, but some people would like to see it be able to pass OS function calls from the Emulation through to the Main AROS OS thus integrating it.
I am ALL for that!!!! :-D LOL I still think you should change the name from AROS to MATT, with all the promotion you're doing. :lol: :lol:
-
Karlos wrote:
Casting that aside, you have this notion of UAE as an "OS", running unhosted on your PC that gives transparent 680x0 emulation.
I'm afraid it's already been done. Amithlon was pretty much just that.
I could be wrong, but it still needs OS ROMs to work.
A replacememnt ROM for Amithlon (and a general update of the whole thing wouldnt hurt) based on open source code would pretty much do the job you are asking, AGA emulation aside.
As for how useful it would prove to be, I can't say.
I think that's exactly what he was asking:) (As I read it).
Amithlon doesn't already do this, since it also requires the official AmigaOS, but by making use of a 68k AROS, UAE (and Amithlon if one so wished) could replace the ROM (and possibly the entire OS) with a free open source version.
Talking of which - would it be possible to have a ROM based on AROS, with the original AmigaOS running on it? I don't know much about AROS, so I've no idea what level of compatibility there is..
-
UAE still needs kickstart, and I have not seen anyone talk about an open source re-implementation of that, or I am blind.
I cant be opensourced until you getourd the kick rom.
-
-------------------------------------------------------
@bloodline
>Booting an A1 with AROS is not that hard, since the A1 has it's own firmware
>(The UBoot BIOS) to bootstrap the hardware... bootstraping a real Amiga
>is much harder since AROS would have to do that itself.. the real
>Amiga's OS and firmware are one and the same.
to what extent is AROS an API as compared to an OS?
If you want to directly boot an A1 not via Linux,
how is this done?:
lets say you buy an A1,
you switch it on,
do you have to create a CD on another machine which you
then boot the A1 with?
How much facilities does A1 UBoot provide?
The code you would run on the A1, how is this created?
is there a cross compiler eg gcc or a cross assembler available
for doing this or do you have to create this first?
I suppose you could go through A1's Linux, but that is cheating,
also cheating would be to borrow Hyperions A1-gcc,
how did the Linux people get Linux on the A1?
A similar problem is creating a game that directly boots up on the A1
bypassing the OS and hitting the hardware directly perhaps through the
UBoot,
For the A1000 I believe they cross compiled the OS from Macs,
this is why Lattice C occurs on both platforms, it was originally a Mac
compiler and they used it to cross-compile AmigaOS (I think):
you then inserted a kickstart disk which loads the ROM to RAM,
and then you booted up with a workbench: floppy,
>UAE runs fine on AROS, but some people would like to see it be able to pass
>OS function calls from the Emulation through to the
>Main AROS OS thus integrating it.
if UAE runs on AROS then that is one way around the problem,
just run the 68k binaries on UAE on AROS,
redirecting UAE through AROS sounds quite a tricky problem,
I think this requires a lot of thought just to understand
the problem properly,
you are attempting to transplant one implementation by a totally
different one,
also some 68k programs may hit the h/w directly which the
redirection wouldnt understand,
it may be more trouble than its worth,
the only neat way I can see to integrate AROS with 68k compatibility is
my initial posting,
that way you completely remove the recompile factor:
both for you: just compile a reimplemented ROM once,
and for programmers: just compile a standard 68k binary just once,
same ROM + same programs then run on all platforms,
and all of www.aminet and geekgadgets and all commercial programs
eg SAS C 650 become available,
once OS3.1 is fully and totally reimplemented you can then
move forwards from this point using emulated 68k but in a
carefully thought through retargettable manner,
ie you would drive arbitrary h/w but through 68k as a virtual CPU,
so eg dos.library can be replaced by newdos.library,
Berndt said in some forum that one problem with dos.library is that
a program can do the following:
f()
{
char x[100] ;
BPTR fh ;
sprintf( x , "filename" ) ;
fh = Open( x , MODE_READWRITE ) ;
.........
}
x is a pointer to a string on the stack, however x can get passed to
another task by Open(), namely one of those filesystem tasks you see
when you run Sysinfo,
this causes a problem that it makes it tricky to have "infinite" stacks,
a popular concept is for all stacks to start at top of memory and grow downwards
via the MMU. This means that the stack is not public memory, ie it cannot
be accessed by other tasks,
dos.library needs to be redesigned so that memory supplied by a task
never gets transmitted to another task,
OS tasks should only receive memory allocated by the OS,
user tasks should be forbidden from allocating OS data structures,
:forbidden by careful API design which makes it impossible,
with exec its quite ok for a program to allocate a struct Semaphore
in fact thats the only way to do it: exec does *not* allocate struct Semaphores
for you,
the user even has to supply the name string which isnt copied by the OS
(see comment in second code fragment on p511 of RKM Libraries 3rd edition),
and these are OS data structures, intuitions API wisely prevents the user
allocating struct Window's,
now if the program does AllocVec( sizeof(struct Semaphore),MEMF_PUBLIC | MEMF_CLEAR);
thats fine,
really it should be the other way round: the only way to create an
OS struct Semaphore should be via some API call eg
struct Semaphore *OpenSemaphore( char *name ) ;
with the OS copying "name" to a properly allocated string and not trusting
the user supplied string
exec's AddSemaphore() shouldnt exist, or at least it should be an internal
private exec call,
these are design subtleties but IMO all the amiga libraries should be
gone through with this subtlety fixed,
OS3.1 has to be reimplemented AS-IS as specified in the RKMs because of
the continuity factor: programmers can then recompile all their programs
to AROS unchanged. via the 68k AGA AROS idea even assembler routines
can remain unchanged in fact recompiling is unecessary just reuse the
existing binary!
However once OS3.1 is reimplemented new improved versions of all the
libraries should be done to run in parallel to the original versions,
another problem to fix with newdos.library is to remove the restriction
on filename length, just replace the inbuilt array by a pointer,
similarly arbitrary length shell command lines should be done,
----------------------------------------
@IonDeluxe
UAE still needs kickstart, and I have not seen anyone talk about an open source
re-implementation of that, or I am blind.
I cant be opensourced until you getourd the kick rom.
-------------------------------------------
there is a blurred line between kickstart and AmigaOS,
apart from the bootstrapping I think most of the kickstart ROM
is just AmigaOS libraries,
if you have reimplemented AmigaOS you may be able to bootstrap
from this:
create by hand the initial minimal interlinked OS datastructures,
so they are self consistent and meaningful,
including execs jump vectors,
create an initial tasks data structures as if it were about
to execute its first instruction,
correctly linked into struct ExecBase,
all interrupt handlers in place,
:kind of AmigaOS in suspended animation,
you need to have total mastery and understanding of your reimplementation to do this,
enable interrupts and now jump
to the first instruction of that task: the breath of life,
that tasks program could be to open dos.library and intuition.library
(DOSBase = OpenLibrary( "dos.library", 0 ) ; etc in machine code)
and then using dos.library it would execute s:startup-sequence,
dos has an API call for executing script files:
SystemTagList( d1 = "s:startup-sequence" , d2 = empty taglist ) ;
dos.library needs to be up and running before you can even think
about s:startup-sequence,
I'm just second guessing here and there's probably many different
ways to do it, bootstrapping is a tricky nightmare!
-
After making the above posting I realised some further things,
1. I think dos.library also needs to be set up by hand in the
bootstrapping because OpenLibrary( ) may require dos.library opened
thus we cannot use it to open dos.library, self-reference,
this is what struct DosLibrary looks like, from dos/dosextens.h:
struct DosLibrary {
struct Library dl_lib;
struct RootNode *dl_Root;
APTR dl_GV;
LONG dl_A2;
LONG dl_A5;
LONG dl_A6;
struct ErrorString *dl_Errors;
struct timerequest *dl_TimeReq;
struct Library *dl_UtilityBase;
struct Library *dl_IntuitionBase;
} ;
so you would do:
DOSBase = AllocVec( sizeof( struct DosLibrary ) , MEMF_PUBLIC | MEMF_CLEAR ) ;
and then set up all the above fields, so it looks like you may
need to also set up utility.library, intuition.library, timer.device,
by hand,
I dont see why you need intuition.library, nothing to do with files
except filerequesters, not sure you even need timer.device initially,
dos.library's Delay() probably uses timer.device, but for the bootstrapping
it may not be necessary,
so probably the bootstrap opening of dos.library
doesnt require intuition or timer (save a lot of work!).
Once the initial dos.library is open,
OpenLibrary() could be used to open intuition.library and OpenDevice() to
open timer,
you also need to set up the jump vectors by hand, possibly 200 functions:
write these functions in position independent code in contiguous memory slots after
the above data structure, then you can load a ready made binary in
one disk read (not using dos.library!),
add the offset of DOSBase to all pointers including the jump vectors,
if you are allowed to use an MMU then the bootstrapping could be reduced
to copying a large ready made binary from disk (without using dos.library),
this binary could even include a ready to start task,
you have to create that binary, but I have already begun this here online,
so you just continue.
One way is to create it in C, compile this to assembler,
via "gcc -S xyz.c -o xyz.s", then customise xyz.s by hand into position
independent assembler. Compile then xyz.s to xyz.o and link into an actual
program prog, prog then can copy the binary subset of xyz.o to contiguous
disk sectors,
2. The issue of 64 bit code, this can be done by extending the
68k Virtual CPU instruction set by inventing our own 64 bit instructions!
as its virtual we can design it any way we wish!
also we can probably do a better job than Motorola, (not difficult!),
I have my Motorola m68k series handbook here, and if the first 4 binary
digits of an instruction are 1010 this is unassigned op code!
So my idea is to invent new 64 bit instructions, not exceeding 16 bits width,
with some new 64 bit virtual registers, lets anticipate the future and make
the registers perhaps 256 bits wide but where we currently only use the
lower 64 bits?
complete with new stack pointer and program counter,
all new instructions would begin with the binary digits 1010,
we also would need to reserve a subset for future expansion,
16 bits is a lot of bits, so reserve 10101 for future use,
our instructions could all begin 10100...........
and they would be designed to be emulator friendly so that UAE and
amithlon can be easily extended. gcc would also need to be customised,
we could even email Berndt before finalising the design,
in case you are interested this is how Motorola allocates the first 4 digits
for 68k assembler, (if I have understood them correctly)
0000 = bit manipulation/movep/immediate,
0001 = move byte
0010 = move long
0011 = move word
(ie 00 = move, next 2 digits = size)
0100 = misc
0101 = addq,subq,scc,dbcc,trapcc
0110 = bcc/bsr/bra
0111 = moveq
1000 = or/div/sbcd
1001 = sub/subx
1010 = unassigned: I'm having that opcode!
1011 = cmp/eor
1100 = and/mul/abcd/exg
1101 = add/addx
1110 = shift/rotate/bit field
1111 = fpu instructions/coprocessor interface/M68040 & CPU32 extensions,
there, 68k summarised in 16 lines!
tempting to write a disassembler/assembler just for the
hell of it!
3. Regarding "improving" OS3.1, improvements could actually be
layered above OS3.1, so eg I mentioned Semaphores,
the improved Semaphores could be implemented via the OS3.1 ones:
remove some of the API calls, introduce others,
such layering will greatly reduce the work required,
alternatively just customise the reimplemented OS3.1 source,
I wonder why Intel CPUs got reimplemented by other companies but noone reimplemented the 68k CPUs?
-
IonDeluxe wrote:
UAE still needs kickstart, and I have not seen anyone talk about an open source re-implementation of that, or I am blind.
I cant be opensourced until you getourd the kick rom.
When someone matures the 68k port of AROS it will probably (The is no technical reason why not) be included with UAE as the Default ROM. Obviously the user could use a real ROM if they wish, but it would not be needed.
-
to what extent is AROS an API as compared to an OS?
If you want to directly boot an A1 not via Linux,
how is this done?:
lets say you buy an A1,
you switch it on,
do you have to create a CD on another machine which you
then boot the A1 with?
How much facilities does A1 UBoot provide?
The code you would run on the A1, how is this created?
AROS is an OS. It currently is able to boot x86 machines and Openfirmware PPC Machines.
If you were to Flash the A1 BIOS with an Openfirmware rom (written for the Terron), then AROS could boot it.
I would expect UBoot provides similar features to Openfirmware, all it takes is for someone to adapt the AROS Boot code.
A System's firmware initilises the hardware, and brings it to a known state. It then Looks for an operating system Loader on the available storage media). Once a Loader is found it is executed. The AROS Loader will then load the AROS "ROM" code into the memory, THat memory is then protected against writing (Since it must be treated as a ROM).
The Loader then preserves all the hardware info from the BIOS into a "safe" location... The loader then jumps to the AROS ROM code. AROS then takes control of the machine. AROS boots.
The Booting precedure is available for view in the AROS source code, and If you have any questions you can visit www.aros-exec.org where the devs can often be found lurking.
-
whoosh777 wrote:
The issue of 64 bit code, this can be done by extending the
68k Virtual CPU instruction set by inventing our own 64 bit instructions!
And at that point your code no longer runs natively even on the lowest common denominator machine: the 68k Amiga.
:-?
-
For the A1000 I believe they cross compiled the OS from Macs,
this is why Lattice C occurs on both platforms, it was originally a Mac
compiler and they used it to cross-compile AmigaOS (I think)
VAX Machines actually. NO Mac of that time would have been powerfull enough (or enough memory/hard disk) to Compile AmigaOS
-
2. The issue of 64 bit code, this can be done by extending the
68k Virtual CPU instruction set by inventing our own 64 bit instructions!
But the only reason to stay with the 68k is to maintain compatibility with the old Amigas... if you want to extend the instruction set virtually, you would do much better to use a brand new CPU.
In answer to your question, the 68k was not extened becasue at the time there was a Paradigm shift from CISC to RISC, and since there was not the software inventment in the 68k that there was in the x86, the decision was made to dump the 68k and move to the PPC.
Note that the x86 instruction set is more RISC like than the 68k, so lends itself better to modern optimisations.
History has shown that the RISC/CISC divide was actually qutie an artificial one, and that a balance between the two is the best architecture.
Personally I would like to have seen the 68k extended in the same way the x86 was with the Pentium.
But the 68k would have to have lost a lot of adressing modes in order to allow high performance operation. This rearchitecturing would have removed the neat orthogonal design of the 68k and rendered it quite incompatibile with the original 68k chips... Defeating the point...
-
@bloodline
Well regarding the addressing modes, I could have done without the memory indirect addressing modes added since the 020. There as good as worthless anyway - the time it takes to fully decode one is simply ludicrous.
Does any amiga software even use them?
The only indirect addressing modes I use for 020+ (and see used elsewhere are)
(d16, aN), (aN)+, -(aN), (d8, aN, xN.w|.l * scale)
and occasionally pc based ones, eg I use (d8, pc, xN.w|.l * scale) for some duffs device style jumps into expanded loops.
-
>UAE runs fine on AROS, but some people would like to see it be able to pass
>OS function calls from the Emulation through to the
>Main AROS OS thus integrating it.
if UAE runs on AROS then that is one way around the problem,
just run the 68k binaries on UAE on AROS,
redirecting UAE through AROS sounds quite a tricky problem,
I think this requires a lot of thought just to understand
the problem properly,
you are attempting to transplant one implementation by a totally
different one,
also some 68k programs may hit the h/w directly which the
redirection wouldnt understand,
Ok, the UAE idea, is just that. Run a 68k version AROS on UAE, and run UAE on AROS.
All 68k programs will run in UAE, and they will make OS calls to the 68k version of AROS Running in UAE... That 68k version of AROS will be specially designed to allow it to call AROS functions through UAE. So whe the 68k program calls the 68k AROS in UAE to open a window... the 68k version of AROS calls the x86 version of AROS and that Opens a window.
when the user clicks on a window that is owned by the 68k version of AROS running in UAE, the event gets passed through to the 68k verison of AROS which passes to the 68k program.
If the 68k program tried to hit the hardware, it will have no problems since the Hardware is emulated in UAE.
-
Karlos wrote:
@bloodline
Well regarding the addressing modes, I could have done without the memory indirect addressing modes added since the 020. There as good as worthless anyway - the time it takes to fully decode one is simply ludicrous.
Does any amiga software even use them?
The only indirect addressing modes I use for 020+ (and see used elsewhere are)
(d16, aN), (aN)+, -(aN), (d8, aN, xN.w|.l * scale)
and occasionally pc based ones, eg I use (d8, pc, xN.w|.l * scale) for some duffs device style jumps into expanded loops.
When I was using 68k, I would tend to use a Memory to Register move, then work in the regs (register to register), then a Register to Memory move.
I really could not be bothered learning all those addressing modes :-( though pre/post incriment/decrement was very handy :-)
-
The register indexed scale mode (d8, aN, xN.w|.l * scale) is incredibly handy and is still fast.
Imagine an array of 32-bit integers, pointed to by a0, and a 16-bit index in d0, you want to move that entry to say d1
move.l (a0, d0.w*4), d1
It's much faster than any pointer arithmetic you can do by manually calculating the address and doesnt trash any registers.
How handy is that?
-
by bloodline on 2004/4/7 9:54:16
--------------------------------------
my questions were:
Quote:
to what extent is AROS an API as compared to an OS?
If you want to directly boot an A1 not via Linux,
how is this done?:
lets say you buy an A1,
you switch it on,
do you have to create a CD on another machine which you
then boot the A1 with?
How much facilities does A1 UBoot provide?
The code you would run on the A1, how is this created?
-----------------------------------------------------------
your answer to this is very interesting, it explains several things
I was wondering about,
---------------------------------------------------------
@bloodline:
>AROS is an OS. It currently is able to boot x86 machines and
>Openfirmware PPC Machines.
>If you were to Flash the A1 BIOS with an Openfirmware rom (written for the Terron),
> then AROS could boot it.
so you appear to be saying it can already be done!
and you also seem to be saying that the only dependencies are that its
Openfirmware, ie the fact its an A1 is irrelevant,
Has this actually been tried out?
What is involved in this flashing of the A1 BIOS?:
lets say someone orders an A1, how do they get the BIOS flashed?
will this clash with running OS4? : what flash does that require, UBoot?
can you switch back and forth between Openfirmware and UBoot?
Have I understood you correctly: you buy an A1, flash the BIOS, download AROS,
boot AROS?
And now can UAE be run just like that on this AROS?
I may go down this path then,
sorry if some of these questions sound ignorant, but I only know in depth
about 68k Amiga,
>I would expect UBoot provides similar features to Openfirmware,
>all it takes is for someone to adapt the AROS Boot code.
are you referring to booting AROS from UBoot??
So are UBoot and Openfirmware the only contenders or are there others?
>A System's firmware initilises the hardware, and brings it to a known state.
>It then Looks for an operating system Loader on the available storage media).
>Once a Loader is found it is executed. The AROS Loader will then load the
>AROS "ROM" code into the memory,
>THat memory is then protected against writing (Since it must be treated as a ROM).
this answers several questions,
now can the MMU be used instead of ROM flashing? ie can UBoot eg remap the
ROM address space to RAM and then copy Openfirmware there and then
metamorphose into Openfirmware or is it more complicated?
>The Loader then preserves all the hardware info from the BIOS into a "safe"
>location... The loader then jumps to the AROS ROM code.
>AROS then takes control of the machine. AROS boots.
does the firmware tell you where all the system memory is located?
are any memory allocation facilities provided or you have to construct these
yourself?
any API provided for reading the drives?
>The Booting precedure is available for view in the AROS source code,
>and If you have any questions you can visit www.aros-exec.org where the
>devs can often be found lurking.
I have to look into this, I feel scared to even look though,
there is something daunting about this, I am afraid to click the link even,
I will click that link, just give me some time!
if I can get an A1 to directly boot AROS and then run UAE above this,
then I think I will go down this path and find out what AROS are doing,
IMO AROS are 10 x as competent as Hyperion,
my interest in this is my own projects that I could run in the AROS
environment so eg I very strictly only use the OS3.0 API and cybergraphics.library,
my interests tend to be nongraphical so eg exec.library interests me
much more than graphics + intuition etc.
Exec really is a masterpiece,
-
by that_punk_guy on 2004/4/7 10:12:07
----------------------------------------------
Quote:
whoosh777 wrote:
The issue of 64 bit code, this can be done by extending the
68k Virtual CPU instruction set by inventing our own 64 bit instructions!
-----------------------------------------------
>And at that point your code no longer runs natively even on the
>lowest common denominator machine: the 68k Amiga.
the 68k architecture anticipates this though:
if you tried executing eg 1010000000000000
which was say at memory location $123400
you would get a "Line 1010 Emulator" exception specifically for
this situation,
I havent done this myself but what I think happens is the
CPU jumps to the trap vector for this exception stored at address $028,
the CPU is in Supervisor mode,
the supervisor stack is in a7 which points indirectly to
the instruction thus:
movea.l 2(a7),a0 ; will move $123400 to a0 (I think),
movea.w (a0),a1 ; will move 1010000000000000 into a1,
which you can now emulate via a subroutine,
my_emulator( a0 = instruction address , a1 = first 16 bits of instruction )
if the extended instructions are thoughtfully designed this emulation
could be ultra fast eg a few machine code instructions,
ie you can patch the 68k CPU to understand the extended instruction set,
-
@bloodline
>Note that the x86 instruction set is more RISC like than the 68k,
how many registers?
0 , 1 , 2 or 3 address code? (max no. of CPU registers per instruction)
can you give some simple examples of x86 assembler?
eg how would you do x = y * z + t where x,y,z,t are all in memory
how does it do floating point maths?
-
You know what I think would be a winner. And I know this is flame bait.
AROS should sit on top of Linux and be able to utilise Linux apps. Sun has just released its Java Desktop System(JDS) which has its StarOffice suite and sits on top of Linux. Its on the cover of a few mags at the moment and it appears to me that it is being hailed merely for being a different distribution and looking like windows.
AROS could get some quick publicity if it offered its own distribution perhaps with some converted Amiga utils or existing Apps running through UAE. At the very least, sitting on top of linux it could call up some of the standard Linux apps and call itself a distribution. It could run Linux based browsers and openoffice. And it should run off the CD like JDS does. You could also include some of the decent free Amiga games and apps on the CD. And you would need a very decent startup theme.
Ok...There's a problem, most likely in that it doesn't support the same GUI library. Doah...
But still, if it could be done, you get points on the board and some interest that could perhaps be diverted into more people being interested in developing AROS further. You could include your linux based development environment on the CD too and see if some Linux people want to go to the trouble of converting some apps to native Amiga.
There I said it.
I know it sounds like prostituting AROS but it might take it to the next level. And you could still work on your native version.
-
>if you tried executing eg 1010000000000000
>which was say at memory location $123400
>you would get a "Line 1010 Emulator" exception specifically for
>this situation,
>I havent done this myself but what I think happens is the
>CPU jumps to the trap vector for this exception stored at address $028,
>the CPU is in Supervisor mode,
if you want to see the default trap handler for the above exception
in action on your system,
download this binary: http://www.whoosh777.pwp.blueyonder.co.uk/crash1010
it is the program:
THE ORIGINAL VERSION OF THIS WAS WRONG AND DIDNT CRASH CORRECTLY!
SO I HAVE EDITTED THIS POSTING WITH A DEBUGGED VERSION THAT CRASHES CORRECTLY!
unsigned int x ;
void (*y)(void);
int main( int argc , char **argv )
{
x = 0xa0000000 ;
y = (void (*)(void))&x ;
y() ;
return( 0 ) ;
}
I got a crash requester:
crash1010
Program failed (error #8000000A).
Wait for disk activity to finish.
Suspend Reboot
exec/alerts.h says that 8000000A is "Line 1010 Emulator error":
#define ACPU_Trace 0x80000009 /* Trace error */
#define ACPU_LineA 0x8000000A /* Line 1010 Emulator error */
#define ACPU_LineF 0x8000000B /* Line 1111 Emulator error */
#define ACPU_Format 0x8000000E /* Stack frame format error */
"Line 1111" is the exception you get if you run a FPU instruction without an
FPU present,
:in theory someone could write an FPU emulator for 68k CPUs lacking FPUs,
(all FPU instructions begin with the binary digits 1111),
that way you could run FPU binaries on non FPU machines,
-
this is embarrassing, but several hours after uploading
crash1010 I was reading a comic about a guy flying an
aeroplane into the future when I suddenly realised
the bug in crash1010, thats why it wasnt crashing correctly!
I've fixed the bug and editted that post with the correct
version that causes the 1010 line emulator trap handler
crash requester,
it now crashes correctly with no. #8000000A,
and I blamed AmigaOS!
anyway I can laugh now,
BTW how do you get the smileys into postings,
I cannot see how to do it, I tried clicking on them
but it doesnt seem to have any effect?
-
how many registers?
AMD64(X86-64) exposes 16 GPRs 64bit registers, while Pentium IV** (with hyper-treading) has 8 + 8 GPRs configuration.
how does it do floating point maths?
About X86-64/AMD64
"Instruction set is designed to offer all advantages of CISC and RISC.
- Code Density of CISC
- Register usage and ABI models of RISC"
Reference document (http://www.amd.com/us-en/assets/content_type/DownloadableAssets/MPF_Hammer_Presentation.PDF)
-
@whoosh777
You do realise that trap based emulation on a real 680x0 is very slow? Hardly suitable for introducing support for new instruction opcodes to a real 680x0 CPU, especially if they were used heavily.
-
>AROS is an OS. It currently is able to boot x86 machines and
>Openfirmware PPC Machines.
>If you were to Flash the A1 BIOS with an Openfirmware rom (written for the Terron),
> then AROS could boot it.
so you appear to be saying it can already be done!
and you also seem to be saying that the only dependencies are that its
Openfirmware, ie the fact its an A1 is irrelevant,
Has this actually been tried out?
What is involved in this flashing of the A1 BIOS?:
lets say someone orders an A1, how do they get the BIOS flashed?
will this clash with running OS4? : what flash does that require, UBoot?
can you switch back and forth between Openfirmware and UBoot?
Have I understood you correctly: you buy an A1, flash the BIOS, download AROS,
boot AROS?
Yes, the fact that it's an A1 is irrelevant. The hardware is a *standard* PPC machine.
First you would have to get an Openfirmware BIOS image from someone. I don't know if these exist, if they do, then One of the other users of the MAI chipset might have one. Check out the Terron.
I assume the A1 BIOS can be flashed by software... most BIOS's can be.
OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware. THat's what they have been written to use. I don't think it's healthy to keep reflashing the BIOS. If one wants to use an Openfirmware PPC machine I would suggest they get an old Mac or a Pegasos2.
On the PC one can use the MMU to load a BIOS image into memory and then use that instead of the ROM BIOS... I assume the same is true of the PPC machines.
The solution to this problem is to get someone with UBoot experience to adapt AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.
>The Loader then preserves all the hardware info from the BIOS into a "safe"
>location... The loader then jumps to the AROS ROM code.
>AROS then takes control of the machine. AROS boots.
does the firmware tell you where all the system memory is located?
are any memory allocation facilities provided or you have to construct these
yourself?
any API provided for reading the drives?
The Firmware tells you how much memory is present (Thoguh it's good practice to check while the OS is booting).
The Memory is always located in it's address space... your question doesn't make much sense :-(. Maybe you mean other memory like PCI space and stuff, yes that sort of information is usually gathered by the BIOS, and AROS uses that information.
AROS provides the Memory allocating functions. The Firmware does not need to know about stuff like that.
Most BIOS firmware does provide a simple API for accessing physical sotrage media... how else are you going to load the OS :-)
if I can get an A1 to directly boot AROS and then run UAE above this,
then I think I will go down this path and find out what AROS are doing,
IMO AROS are 10 x as competent as Hyperion,
my interest in this is my own projects that I could run in the AROS
environment so eg I very strictly only use the OS3.0 API and cybergraphics.library,
my interests tend to be nongraphical so eg exec.library interests me
much more than graphics + intuition etc.
Exec really is a masterpiece,
If you want to work on the PPC version of AROS why not help the PPC guys get it running on UBoot?
I think Hyperion are perfectly competant, it's hard work writing an OS from Scratch.
You project should run fine in AROS, if you have a PC there, then you could compile your Apps for AROS right now and use them on your PC with AROS :-)
Exec is a masterpeice! And getting to look at the Exec sources in AROS is really nice :-)
-
@bloodline
>Yes, the fact that it's an A1 is irrelevant. The hardware is a *standard* PPC
>machine.
this thought is running through my mind:
reflash A1 and then run Morphos,
reflash Pegasos and then run OS4,
reflash either and run AROS,
>First you would have to get an Openfirmware BIOS image from someone. I don't know
>if these exist, if they do, then One of the other users of the MAI chipset might
>have one. Check out the Terron.
I assume such BIOS images are "public domain",
I think I have to buy the machine first, I like doing things in the
correct sequence,
>I assume the A1 BIOS can be flashed by software... most BIOS's can be.
can it also be backed up?
would it just be a matter of getting the MMU to write enable the BIOS
and then copy the bitmap?
>OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware.
>THat's what they have been written to use. I don't think it's healthy to keep
>reflashing the BIOS. If one wants to use an Openfirmware PPC machine I
>would suggest they get an old Mac or o Pegasos2.
ok, was there any thinking behind their decision to use UBoot?
maybe someone with a Pegasos2 could make their Openfirmware BIOS image available,
ditto A1 UBoot,
> On the PC one can use the MMU to load a BIOS image into memory and then use that
>instead of the ROM BIOS... I assume the same is true of the PPC machines.
sounds a much better approach,
> The solution to this problem is to get someone with UBoot experience to adapt
>AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.
>The Firmware tells you how much memory is present
>(Thoguh it's good practice to check while the OS is booting).
>The Memory is always located in it's address space... your question doesn't make
>much sense.
I was thinking in terms of the classic machine where the memory may be
in several noncontiguous segments,
it sounds like you are saying its all remapped into 1 contiguous slot,
>Maybe you mean other memory like PCI space and stuff,
>yes that sort of information is usually gathered by the BIOS,
>and AROS uses that information.
>AROS provides the Memory allocating functions. The Firmware does not need to know
>about stuff like that.
ok, not a major problem,
>Most BIOS firmware does provide a simple API for accessing physical
>sotrage media... how else are you going to load the OS
I was wondering about this,
eg if you have some arbitrary storage device eg USB or SCSI or IDE,
I was wondering how a low level initial API deals with arbitrary h/w,
but maybe the storage device sorts itself out,
>If you want to work on the PPC version of AROS why not help the PPC guys get it
>running on UBoot?
quite possibly, maybe a good approach would be the more general problem of
layering Openfirmware above Uboot,
if Uboot and Openfirmware are both quite simple then this layering may not
be a big deal,
and then layer the reverse way round,
what I may do is buy an A1, and then fool around with the UBoot to try
and understand it and then look into what the AROS people are doing,
>I think Hyperion are perfectly competant, it's hard work writing an OS from Scratch.
I challenged one of them to tell us in detail what they are doing:
on an hour by hour basis, or even on a day by day basis,
which OS library or subsystem, which API calls, are they debugging or
writing new stuff, is the delay because of quantity of stuff or
difficulty of stuff,
is it graphics.library or dos.library or what?
the huge time they are taking must be occupied doing something,
exactly what is that which is so time-consuming,
I realize that coding is very time consuming and an interesting program
feature could take 1 week to achieve,
I got no reply,
for all I know they are lying in hammocks sipping amicola and reading
star-trek-fanzines,
basically I asked them for a captains-log, and got silence,
I emailed Hans-Joerg requesting their 68k hosted cross compiler,
I got no reply, not even "no I cannot send you this because...",
the whole point of a 68k hosted cross compiler is to run it on a
68k machine,
Their website tells you next to nothing,
they have had a whole suite of cross compilers available since last year,
and they still havent released it, they promised on their website on
Christmas day to deliver this.
For Christmas 2002 we were promised OS4 under christmas trees and
on Christmas 2003 all we got was a promise under a christmas tree,
:they cannot release stuff thats already been done, time is of the essence,
you see I think now that the OS4 shown at Pianeta was merely a hacked
UAE, OS4 maybe doesnt exist,
KMOS are behaving exactly like Hyperion, no announces, no presence,
no nothing, they sound like a stooge,
>You project should run fine in AROS, if you have a PC there, then you could
>compile your Apps for AROS right now and use them on your PC with AROS
I only have 68k machines, 2 68000 A500s and a 68030 A1200,
I will try and get some stuff onto AROS though this will probably wait till I am
on PPC or PC, I have lots of useful utilities that I have written to manage
my own system,
eg I wrote a recursive date sorter, feed it a list of directories
eg some partitions and it will recursively sort the entirety by date,
it will cope no probs with an entire CD, (you need enough ram for the
list to fit: 1/2 Gig full partition on my 14 meg 030 was no problem)
it takes n log n time so there is no noticeable slowdown,
it just munches its way through whatever you feed it,
it can cope with up to 2^32 entries,
not a big deal but very fast + useful, took 1 or 2 days to write + debug,
:I use it to find out what I was last up to on a partition if I havent
used it for a long time,
I will upload the 68k version to my site later tonight:
http://www.whoosh777.pwp.blueyonder.co.uk/datesorter.lha
(not there yet as I type this),
example usage:
dates -r ram: -n c: -r -p #?.c df0: -n df1:
=> recursively scan ram:, then non recursively scan c:,
then recursively scan df0: filtering in pattern #?.c,
then non-recursively scan filtering pattern #?.c df1:,
merged sorted list is output,
:you can filter in any pattern,
for usage info:
dates ?
or
dates
>Exec is a masterpeice! And getting to look at the Exec sources in AROS is
>really nice
it could help me understand the original exec,
-
------------------------------------------
@bloodline
Ok, the UAE idea, is just that. Run a 68k version AROS on UAE, and run UAE on AROS.
All 68k programs will run in UAE, and they will make OS calls to the 68k version
of AROS Running in UAE... That 68k version of AROS will be specially designed to
allow it to call AROS functions through UAE. So whe the 68k program calls the 68k
AROS in UAE C
o open a window... the 68k version of AROS calls the x86 version of AROS and that
Opens a window.
when the user clicks on a window that is owned by the 68k version of AROS running
in UAE, the event gets passed through to the 68k verison of AROS which passes to
the 68k program.
If the 68k program tried to hit the hardware, it will have no problems since the
Hardware is emulated in UAE.
------------------------------------------
I am gradually starting to understand the problem,
some ideas on this:
break UAE into 2 programs: UAE_chipset_emulator and UAE_68k_emulator,
implement UAE_chipset_emulator via AROS API calls,
run this as a background prog from AROS: it will read + write protect
the classic chipset address range: any read or write accesses will be
redirected to AROS API calls so eg:
a word write of #$c000 to dff09a will be implemented via
AROS Enable() but with SysBase->IDNestCnt unchanged,
No ROM will be used, classic 68k programs will be directly fed to UAE_68k_emulator
which will directly access the data structures of AROS,
x86 AROS may need to be big endian,
problem: (there may be other problems too),
if a 68k prog accesses a jump vector eg jsr -444(a6) for OpenDevice,
the jump vector may be PPC native so you dont want the instruction
emulated:
a huge hack around this is to put PPC native code in the upper half of memory,
ie addresses where bit 31 is 1, and 68k code in the other half,
when the emulator is active read-protect the upper half of memory,
when inactive execute-protect the lower half,
this way when the emulator attempts to read the PPC instruction from
the upper half, you get an exception which toggles
from emulator to PPC CPU,
likewise if the PPC tries to execute a 68k instruction from the lower half,
you get an exception toggling from PPC to emulator,
its just an idea and I havent thought it through too deeply,
but maybe you can fine tune it into real architecture,
-
>OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware.
>THat's what they have been written to use. I don't think it's healthy to keep
>reflashing the BIOS. If one wants to use an Openfirmware PPC machine I
>would suggest they get an old Mac or o Pegasos2.
ok, was there any thinking behind their decision to use UBoot?
I think they choose it because it was different from the other PPC machines which all went Openfirmware, That way they could lminit the machine which OS4 runs on, and that it was suitable for thier needs.
> The solution to this problem is to get someone with UBoot experience to adapt
>AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.
>The Firmware tells you how much memory is present
>(Thoguh it's good practice to check while the OS is booting).
>The Memory is always located in it's address space... your question doesn't make
>much sense.
I was thinking in terms of the classic machine where the memory may be
in several noncontiguous segments,
it sounds like you are saying its all remapped into 1 contiguous slot,
System Ram (Which AROS calls Fast Mem) is. Note AROS calls the first 16meg of System Ram Chips Mem, as this is DMA able ram.
>If you want to work on the PPC version of AROS why not help the PPC guys get it
>running on UBoot?
quite possibly, maybe a good approach would be the more general problem of
layering Openfirmware above Uboot,
if Uboot and Openfirmware are both quite simple then this layering may not
be a big deal,
and then layer the reverse way round,
what I may do is buy an A1, and then fool around with the UBoot to try
and understand it and then look into what the AROS people are doing,
AROS is really modular. One would not layer OF (Openfirmware) on top of UBoot, one would take out the OF boot code and replace it with UBoot Boot code. The advntage of AROS being opensource is that it can be hacked to suit the needs of the user (ie you) :-)
>You project should run fine in AROS, if you have a PC there, then you could
>compile your Apps for AROS right now and use them on your PC with AROS
I only have 68k machines, 2 68000 A500s and a 68030 A1200,
I will try and get some stuff onto AROS though this will probably wait till I am
on PPC or PC, I have lots of useful utilities that I have written to manage
my own system,
If you find a PC in the trash/skip/bin then dig it out and run AROS on it, I have several junk machines found that run AROS fine.
>Exec is a masterpeice! And getting to look at the Exec sources in AROS is
>really nice
it could help me understand the original exec,
The AROS code does the same as the original code... so it's a great place to really admire the design.
-
whoosh777 wrote
I think you need to chat to Crumb...
But Keeping 68k Apps away from x86 apps will be better in the long term... espeacially when adding features like Memory Protection, which 68k apps simply cannot work under.
Basicly keep 68k in the emulator and only let certain OS calls out to the Main AROS, so that the 68k programs can function in the same windowing environment as the x86 apps (without actually going near them).
-
----------------------------------------------------------------
@Karlos
You do realise that trap based emulation on a real 680x0 is very slow?
Hardly suitable for introducing support for new instruction opcodes to
a real 680x0 CPU, especially if they were used heavily.
----------------------------------------------------------------
one way out is:
use traps as I suggested, here real 68k instructions are at full speed,
but as you point out the extended instructions will be emulated slowly,
SR + PC have to be backed up by the h/w (and possibly other stuff)= 2 move's,
2 moves to get address + instruction, jsr + rts to the emulator code,
bitfield extractions + switch statements, soon be exceeding 20 instructions,
so,
simplified JIT emulation could speed this up, replace the offending instruction by
a direct bsr to its emulation, the extended instructions would need to be
designed to be the right size so a bsr will fit, could be done by always following
it with 2 no-op NOP's, (a general bsr requires 6 bytes),
:this way second time round the only overhead is jsr + rts,
self modifying code,
BTW regarding neat 68k instructions, I think movem of 68000 is very
effective eg:
movem.l d0/d1/d2/d3/d4/d5/d6/d7/a0/a1/a2/a3/a4/a5/a6,-(a7)
:a 4 byte instruction to backup 15 registers,
normally would require 15 instructions:
move.l a6,-(a7)
move.l a5,-(a7)
....
move.l d0,-(a7)
(hope I got the order correct),
----------------------------------------
@Hammer
AMD64(X86-64) exposes 16 GPRs 64bit registers, while Pentium IV**
(with hyper-treading) has 8 + 8 GPRs configuration.
-----------------------------------------
16 sounds a good decision,
what about 486 and earlier CPUs?
(the speed advantage of x86 makes me believe that something about
their architecture must be very good, I am curious to know what that is),
@BigBenAussie,
if you have AROS on Linux, why not just use the Linux apps directly on Linux!
for office use why not buy Windows and use MS Apps,
if you have an office you can probably afford this
purchase,
what would be interesting would be Linux-in-a-window to run on any Amiga,
-
@whoosh777
A trap based emulation which can replace each "emulated" instruction with a jump to handling code the first time it is encountered is probably the way to go. I think that's how stuff like oxypatcher/cyberpatcher work anyway.
As for movem, you'd want to check the CPU before making any performance assumptions. On the 68040, for instance, it often takes longer than multiple move.l instructions (although I'm not totally sure if the same is true for 68060).
-
what about 486 and earlier CPUs?
Just 8 32bit GPRs (386 and above).
(the speed advantage of x86 makes me believe that something about their architecture must be very good, I am curious to know what that is),
It would be more on the micro-architecture side than the ISA side. "Bang per buck" and legacy support (a.k.a "software investment protection") are the other strengths of X86.
Note that IF PPC32 ISA is a "real RISC", the need for decoding/'cracking' into smaller RISC instructions wouldn’t be required in the PPC 970(52million transistors beast)(IBM's own "Athlon" but applied for PPC32 ISA).
-
@bloodline
who is Crumb?
>If you find a PC in the trash/skip/bin then dig it out and run AROS on it,
>I have several junk machines found that run AROS fine.
I am trying to decide which path to take, PC or A1?
if I buy an A1 I think I can sell it back to Eyetech,
this reduces the risk of making this purchase,
re: reflashing ROMs, could you also run Mac's OS on Pegasos + A1
as well as Morphos + OS4 + AROS on Macs?
Some AROS questions:
1. what compiler(s) are used for recompiling AROS programs?
2. are commercial AROS programs allowed, eg could they sell an
AROS version of IBrowse?
because if AROS is free programs only I see this as a problem,
I am happy to contribute a lot of work for free and I have done for 68k,
but I would also like to sell some programs,
ambitious free programming work is a very good way to learn,
but you can only do it for so long,
if a developer spends 8 months on an OS3.1 program,
then they will be thinking:
shall I give it for free to AROS
or shall I sell it to Morphos + OS4 + 68k + Amithlon people,
now if they can sell it to AROS people they are more likely
to choose the AROS option,
one way out is to only do a 68k version here they can sell it
anywhere they like which is probably what will happen,
some programs will be done for free and some will be very high quality,
but you wont have row upon row of fantastic stuff, just the occasional gem,
the project would certainly succeed but in the spirit of
gnu,
it will become like http://ftp.gnu.org/gnu where 5% is fantastic eg gcc,
5% is self referential eg sed + awk + automake
(you need this because you need this!) and the rest requires a lot
of work to even determine what it is!
ie row upon row of "what on earth is this bloated archive"?
rpm is a red-hat self referential program, current rpm is some 9 meg compressed,
do I want it? no, so why do I use it? because there is lots of interesting stuff
only available in this format. If everything on the internet is in Betelgeusian
then I have to learn that,
I dont know whether Linux allows commercial programs,
put another way if AROS is free things only then there is a danger of
becoming a charity to impoverished Amiga users (such as me :( )
but if commercial stuff is allowed then the future is bright,
the government used to give free glasses here, (no longer though)
but they were small lensed plastic framed Buddy Holly ones,
they also provided £15 gold rimmed circular John Lennon glasses,
I like your NHS glasses!
are you poor? or just mean?
commercial glasses OTOH are super duper scratch proof + cool looking with nice shaped lenses, well designed
nose-pieces and you have a big choice also they fit better on your face,
you get free education also but apart from some exceptional schools you may
have to share your class with some thugs, but pay (through your nose) and you
get conscientious teachers + fancy equipment and all sorts of extra opportunities,
you want your sprog to learn the piano?
we'll get sproggo to grade 9 on a Steinway with this top tutor, just £40 per lesson,
(I think its called a Steinway and I think its grade 9 but I could be wrong)
-------------------------------------------------------------------------
@karlos
>A trap based emulation which can replace each "emulated" instruction with a jump
>to handling code the first time it is encountered is probably the way to go.
>I think that's how stuff like oxypatcher/cyberpatcher work anyway.
I think the only way to get faster will be via full blown JIT which
is going to be months and months of work, (68k JIT emulation of 68k),
with such a JIT something like move.l d0,d1 will translate as is,
its the position dependent instructions that will be the problem,
pc-relative instructions will also be a problem because the relative
distance can change,
>As for movem, you'd want to check the CPU before making any performance
>assumptions. On the 68040, for instance, it often takes longer than
>multiple move.l instructions (although I'm not totally sure if the same is true
>for 68060).
I have found that the safest way to write assembler is often
just to use simple minded instructions:
the clever instructions often run slower,
68k actually has some instructions which save neither space nor time!
just use an, dn, xyz(an), -(an), (an)+,
and your code will be pretty good, as well as straightforward to
port to a different CPU,
:it will also be much easier to read + debug,
In fact this applies to C as well, if you write a program in a simple
to understand way its often faster than if you try to make it fast,
2 things that assembly language programmers often forget:
1. instructions need to be loaded from ram:
so eg "move.l d0,d1" doesnt reference ram, but the instruction
itself 00 10 001 000 000 000 has to be loaded from ram:,
2. caches:
loop instructions and the stack are almost certainly in a cache so
are read much faster than you think,
-
@whoosh777
who is Crumb?
An A.orger who wants inline 68k emulation in x86 AROS :-)
>If you find a PC in the trash/skip/bin then dig it out and run AROS on it,
>I have several junk machines found that run AROS fine.
I am trying to decide which path to take, PC or A1?
if I buy an A1 I think I can sell it back to Eyetech,
this reduces the risk of making this purchase,
re: reflashing ROMs, could you also run Mac's OS on Pegasos + A1
as well as Morphos + OS4 + AROS on Macs?
I'm not sure Eyetech would want to buy your A1 back... not with out a massive loss (more than the Price of a PC!).
I suggest you talk to people and look around for the machine that best suits your needs for the lowest cost.
(click the link for BlackTroll for great prices on AROS PCs)
Yes you can run MacOS on both the A1 and the Pegasos, by using a special program called "Mac-on-Linux", but then you need to run Linux too.
MOS and OS4 don't run on the Mac. AROS should though.
Some AROS questions:
1. what compiler(s) are used for recompiling AROS programs?
The Default Compiler is gcc. One AROS dev works in SAS/C on a real Amiga though. But to compile for the x86 you need to use gcc. We also have an x86 Assember program, as well as BASIC, False and Python all included with AROS.
2. are commercial AROS programs allowed, eg could they sell an AROS version of IBrowse?
Of course you can run commercial apps on AROS. That fits with my personal computer paradigm:
1. You pay for the harware.
2. You pay for the drivers.
3. You pay for the software.
4. But the OS is free and open source.
In fact the AROS licence even allows you to sell AROS, with certain conditions applying, this is how the MorphOS team are able to use the AROS sources (they bug fix the code they use).
I hope to see comercial software appearing for AROS once it gets better established.
-
@bloodline,
from your reply I think I will go down the AROS path,
my line of action being:
1. decide on machine eg A1 or PC?
2. buy machine,
3. familiarise myself with machine,
if its A1 familiarise myself with UBoot,
4. look into what AROS are doing:
either to contribute directly
or to write or port things to AROS,
so step 2 could be in 3 weeks and step 4 in 7 weeks time,
probably I will always be on the outermost periphery of AROS
and all other projects as I prefer to be standalone,
Getting AROS to boot directly on an A1 sounds a very high priority
project, so if it hasnt been completed I may join that project,
it also sounds very interesting,
I understand AROS already runs above Linux on A1 so AROS is there
already but not the way many people want,
I am sure I can contribute things to AROS though it may be
several months before I can contribute something substantial,
ambitious projects are slow moving, this is why I am reacting slowly,
I can see that AROS only projects will help tip the balance towards AROS,
"portability" is a virtue but "porting" is strategy,
>>who is Crumb?
>An A.orger who wants inline 68k emulation in x86 AROS
if you compile AROS with big endian Intel gcc then you can have
seamless 68k + x86 AROS integration using some variant of my
suggestion,
read + execute exceptions would toggle between emulated and nonemulated
instructions,
Amithlon has a big endian Intel gcc on www.aminet.net,
If the bytes of RAM are $12 $34 $56 $78 ...........
a big endian CPU sees this the way I have written it and
sees the first int of memory as $12345678
a little endian CPU sees this as .......... $78 $56 $34 $12
and reads the first int (address 0) as $78563412 totally different from
what the big endian CPU sees,
thus the 68k emulator is in danger of clashing with the x86 CPU,
eg addresses will be mangled,
resolve all this via a big endian Intel gcc compile of AROS:
68k and x86 can then access identical OS data structures,
>I'm not sure Eyetech would want to buy your A1 back...
>not with out a massive loss (more than the Price of a PC!).
they have a buy back policy with a depreciation formula,
not sure where I read this, but you could calculate how much
you lose,
I would only sell back the core machine, I would keep the peripherals,
the peripherals anyway wouldnt be bought from Eyetech
Would there be any point in creating your own AROS PPC platform?
:you could then open up the marketting policy,
>I suggest you talk to people and look around for the machine that
>best suits your needs for the lowest cost.
>(click the link for BlackTroll for great prices on AROS PCs)
>Yes you can run MacOS on both the A1 and the Pegasos,
>by using a special program called "Mac-on-Linux",
>but then you need to run Linux too.
I was thinking of directly doing it by reflashing the ROM,
but Mac being Mac probably have some proprietory obstacle to prevent this,
>MOS and OS4 don't run on the Mac. AROS should though.
>The Default Compiler is gcc.
this is the deciding factor,
which versions?
I hope you have gcc2.95.3-4 even though its not the most current,
is it a specifically AROS gcc or do you reuse generic ones?
Have you got 68k hosted cross compiler gcc's (PPC , Intel) for AROS?
(preferably gcc2.95.3-4),
>One AROS dev works in SAS/C on a real Amiga though.
SAS/C 650 compiles considerably faster (seconds) than gcc (minutes)
and produces slightly better code unoptimised than gcc -O2 optimisation,
gcc has its own strengths,
if I can use either I always use SAS/C, sometimes though
the only way to do something is with gcc,
eg ISTR that a really huge static array such as 1 million entries
(eg automatically generated look up table such as
int x[]={ 1 , 2 , 3 , ..., 1000000} ;} )
will crash the Amiga linker but I think gcc will be ok,
>But to compile for the x86 you need to use gcc.
>We also have an x86 Assember program, as well as BASIC, False and Python all
>included with AROS.
you realise that gcc is also an assembler, the moment a platform has gcc
it automatically has an assembler:
gcc -c xyz.s -o xyz.o
will assemble xyz.s, gcc uses nonstandard cross-platform assembler syntax though
eg for 68k gcc:
.text
.even
.globl _function
_function:
move.l #0,d0 /* this is a gcc assembler comment */
rts
to compile function()
it doesnt understand xref and xdef, .globl is xdef, xref is implicit,
so it wont assemble traditional 68k progs, they need fixing for gcc
I think it uses c style #define's for its macros, so it wont understand
Metacomco's macros,
on x86 it would also be .text, .even, .globl, /* comments */,
which reduces the learning curve,
to compile eg specific 68040 instructions you would type:
gcc -m68040 -c xyz.s -o xyz.o
(the default is 68000 + no FPU),
gcc -m68881 -m68020 -c xyz.s -o xyz.o
for 68020 + FPU code,
>Of course you can run commercial apps on AROS.
>That fits with my personal computer paradigm:
>
>1. You pay for the harware.
>2. You pay for the drivers.
>3. You pay for the software.
>4. But the OS is free and open source.
this is a deciding factor for me,
so eg commercial AROS IBrowse can be closed source?
(I think they wont do it open source)
>In fact the AROS licence even allows you to sell AROS,
>with certain conditions applying, this is how the MorphOS team
>are able to use the AROS sources (they bug fix the code they use).
>
>I hope to see comercial software appearing for AROS once it gets better established.
>
there is an opportunity immediately available for you here:
iospirit announced they have abandoned OS4 development,
there was a link to this from AmigaWorld.net at the time of the
KMOS takeover,
ask iospirit if they will recompile + sell IBrowse to AROS,
they have nothing to lose by doing this,
they already have an up and running website for selling IBrowse,
IBrowse is currently the flagship commercial program for the Amiga,
this would be a major coup,
tell them that you are working towards directly booting AROS on the A1,
AWEB is also now open source, so recompile that and you also get that,
(possibly it may need some work to compile it on gcc)
-
Amithlon has a big endian Intel gcc on www.aminet.net,
They have a 680x0 hosted gcc that produces x86 code for amithlon.
AFAIK, there is no such thing as big endian x86.
resolve all this via a big endian Intel gcc compile of AROS:
68k and x86 can then access identical OS data structures,
Again, I have no idea what you mean by "big endian intel".
x86 is little endian. 680x0 is big endian. Each has it's advantages and disadvantages.
Fundamentally the only difference is that on a big endian system, the lowest byte address of a multibyte object is the most significant, whereas for a little endian system, its the least significant.
Thus 680x0 is big endian by definition but its a bit odd if you consider register-only byte/word/long operations - the effect is litte endian. That is, a byte/word operation always affects the LSB/LSW of the register. Do the same thing on a 32-bit memory operand and you find the MSB/MSW is affected:
Imagine you have the value 0x01000001 in a memory address pointed to by (a0)
move.l (a0), d0
add.b #1, d0 ; least sig byte is affected
move.l d0, a0
gives 0x01000002
is completely different behaviour to
add.b #1, (a0) ; most sig byte is affected
which gives
0x02000001
On little endian systems like x86, the equivalent code for each of the above fragments generates the same result, affecting the LSB in both cases.
Of the common CPUs kicking around, only load and store architecture (as typified by RISC) tend to support endian swapping modes since all operations they perform are on registers. Never operating directly on memory operands and providing both big and little endian load/store instructions is how the PPC does it, for example.
-
by Karlos on 2004/4/11 1:05:26
Quote:
>>Amithlon has a big endian Intel gcc on www.aminet.net,
>They have a 680x0 hosted gcc that produces x86 code for amithlon.
>AFAIK, there is no such thing as big endian x86.
not totally sure, I have this installed,
I created ram:xyz.c
extern int x ;
void f()
{
x = 0x12345678 ;
}
and now compiled it:
bin/i686be-amithlon-gcc -O2 -S ram:xyz.c -o ram:xyz.s
this generated x86 assembler:
.file "xyz.c"
.version "01.01"
gcc2_compiled.:
.text
.align 4
.globl f
.type f,@function
f:
bswap %ebp
pushl %ebp
bswap %ebp
movl %esp,%ebp
movl $2018915346,x
movl %ebp,%esp
popl %ebp
bswap %ebp
ret
.Lfe1:
.size f,.Lfe1-f
.ident "GCC: (GNU) 2.95.3 20010315 (release/lcs-2002-02-08)"
not sure what its doing, it looks like neither endianess,
anyone understand x86 assembler?
$12345678 is 0001 0010 0011 0100 0101 0110 0111 1000 in binary,
the above code has
$2018915346 which is 0010 0000 0001 1000 1001 0001 0101 0011 0100 110
which looks totally different,
not sure whats going on,
bswap looks like some kind of byte reversal but what is
it reversing?
(BTW it looks like its using some 1-address code
which is a good move IMO)
I was under the impression that it generates big endian code,
I think its also available for other platforms such as PPC,
when I say big endian, what I mean is that
for 2-byte word and 4-byte long accesses it will reverse the
byte order before accessing ram:
say we have:
int *x;
x* = $12345678 ;
on big endian we would get:
byte[ x ] = $12 ; byte[ x + 1 ] = $34 ; byte[ x+2] = $56 ; byte[ x+3]= $78 ;
(*A*)
on little endian (read carefully!):
byte[ x+3 ] = $12 ; byte[ x+2 ] = $34 ; byte[ x + 1 ] = $56 ; byte[ x ] = $78 ;
ie
byte[ x ] = $78 ; byte[ x + 1 ] = $56 ; byte[ x + 2 ] = $34 ; byte[ x + 3 ] = $12 ;
so to implement big endian on little endian:
x* = byte_reverse( $12345678 ) ; /* some CPUs may have an assembler instruction for this */
which would do
x* = $78563412 ;
ie
byte[ x ] = $12 ; byte[ x+1]=$34 ; byte[ x + 2 ] = $56 ; byte[ x + 3 ] = $78 ;
identical to what big endian would do see (*A*) above,
so as long as all memory accesses are intercepted with a byte reversal
by the compiler then Intel will behave as if it were big endian,
>>resolve all this via a big endian Intel gcc compile of AROS:
>>68k and x86 can then access identical OS data structures,
>Again, I have no idea what you mean by "big endian intel".
rewording will help:
((big-endian-ram)-emulation) gcc for Intel,
usual Intel CPU but a compiler that
intercepts all memory reads + writes by byte reversal:
for reads:
1.read memory
2.byte reverse it
3. use it,
for writes:
1. have data
2. byte reverse it
3. write it
>Thus 680x0 is big endian by definition but its a bit odd if you consider
>register-only byte/word/long operations - the effect is litte endian.
>That is, a byte/word operation always affects the LSB/LSW of the register.
>Do the same thing on a 32-bit memory operand and you find the MSB/MSW is affected:
>
>Imagine you have the value 0x01000001 in a memory address pointed to by (a0)
>
>move.l (a0), d0
>add.b #1, d0 ; least sig byte is affected
>move.l d0, a0
>
>gives 0x01000002
>
>is completely different behaviour to
>
>add.b #1, (a0) ; most sig byte is affected
>
>which gives
>
>0x02000001
I wasnt aware of this subtlety, usually inconsistencies such as this are
a sign of bad design,
with good design everything should be logically harmonious,
what they should have done is that the most significant register byte should
be affected and that eg
move.b (a0),d0
would load the number to the most significant byte of register d0,
I think you have located another design flaw of the 68k architecture,
maybe we should reimplement and improve 68k! eg:
fix this problem,
remove all the silly addressing modes,
remove pointless opcodes,
make all registers general purpose: where it currently says
effective address=mode xxx register xxx
we replace this by
effective address=mode xx register xxxx
(x = binary digit),
make exception frames store their size,
create huge caches,
the 68030 MMU OTOH is very well designed,
much better than the PPC MMU,
You know that PPC has a CPU flag that allows you to select whether
its big or little endian,
BTW regarding things which look fast but arent:
I was studying CPU registers + stack in supervisor mode
and other system things when I observed
that my A1200 supervisor stack pointer is at the top of chip ram ie
$200000,
so I thought I would speed it up by moving it to fast ram, I did this,
and then timed some graphics + disk intensive stuff and found it
made no difference at all!
-
Dude, your posts are huge :-D
Let's see.
So, there is a compiler for amithlon that generates x86 code that does automatic byte reversal for operands during load/save to memory, thus giving a "big endian" data model that the 680x0 model is compatible with.
This makes some sense. However, this also means that you have totally killed the benefits of a CPU capable of memory operands for the majority of normal code.
This is because you have to (for anything bigger than a byte) load the operand from memory to a register, swap it from its "big" endian representation to little endian, perform an operation on it, reverse it again and pump it back out to memory.
Sound familiar? It should. You turned your "complex addressing mode" x86 into a load/store architecture.
Unfortunately, x86 doesn't have the register count to make load/store based code effective. In fact, it is especially bad at it since it was (like the 680x0) designed to be able to have memory operands for most instructions.
Conversely, load/store code is the domain of CPUs like the PPC, where all operations are on registers and to compensate for lack of memory based operands, you have plenty of registers.
Basically, if what you say is true, the compiler generates code that is "big endian" data format compatible at the expense of a large amount of code required to wrap fairly simple operations. In other words, speed is secondary to compatibility.
Can you imagine what any half complicated C expression compiles to where variables are loaded from ram each time?
Instead of being able to perform arithmetic on a register using a memory operand, you have to load the memory operand to another register, byte swap it etc.
You also now see why the 1-address code model ain't really so hot at all (sorry, but it's true. x86 architecture comes straight from pocket calculator era, hence the "accumulator" register ;-) )
Back onto 68K
I disagree that the 680x0 architecture is flawed by its "odd" register behaviour, but I threw it in purely to show that endianness is even more perculiuar than many people think. Things are the way they are for a reason. It would be a flaw if it wasn't well documented that the registers behave that way and you just assumed they behaved the same way as memory ;-)
The 68K has one of the nicest architectures IMHO. Too bad motorola canned it. The memory indirect addressing modes are a bit pointless, but other than that it is a fine design.
GPUs are just ace for this type of oddness. I know ones which have little endian 16-bit words but big endian 32-bit words etc.
Yeah I know the PPC allows big/little endian operation. That's easy for load/store based architectures and it's not alone in being able to do it. There are ARM cores with the same ability.
As for the supervisor stack thing:
1) are you sure that the SSP wasnt already remapped somewhere else in fast ram buy your 030?
2) the system doesnt exactly spend long in supervisor mode anyway. Most OS functions do the bulk of their work in user mode.
-edit-
PS: Your asm code for the x86 $2018915346 is a decimal literal that is 0x78563412 in hex.
Thats your 0x12345678 with the bytes reversed. If your gcc compiler does create "big endian" data, it makes sense that integer literals would get statically converted in this fashion - the variable "x" now contains 0x78563412 as far as the x86 is concerned, but a 680x0 would see it as 0x12345678, which is what you are indending.
-
maybe we should reimplement and improve 68k! eg:
fix this problem,
remove all the silly addressing modes,
remove pointless opcodes,
make all registers general purpose: where it currently says
effective address=mode xxx register xxx
we replace this by
effective address=mode xx register xxxx
(x = binary digit),
make exception frames store their size,
create huge caches,
Fine, as long as you recognise it wont be object code compatible with any existing 680x0 :-D
If we are dreaming about the perfect 680x0...
As for effective addresses, as long as you have
operation , register
operation register,
for all the common instructions I'd be happy. For example, there is no
eor , dN
which is a bit of a bummer.
64-bit data registers and a new size type reflecting them would be nice. Operations involving them would naturally require extended opcodes since the existing 16-bit opcode word format has no ability to handle 8-byte elements.
However, youd never see this from the assembler perspective and hence have no idea that
add.q #1, d0
has a different opcode layout than
add.b/w/l #1, d0
Also, make sure you add some new muls/mulu operations that can do the long arithmetic and use a single 64 bit register result.
Another nice feature I'd like to see is an extended number of registers. Now, I know you can't actually do this blithely and have d9, d10 etc., because the existing opcode format doesnt allow it.
Instead, have a register "swap space" that allows you to have say 32 data registers in total and the ability to select which 8 of them are currently mapped to d0-d7.
The mapping can be done in such a way that it's impossible to have any of d0-d7 mapped to the same register. The simplest way to do this is to divide the full register space into "banks" (4 for a 32-register version), and you can set which bank dX is in.
For example, you might have a bank set opcode
setreg d0-d7, 0 ; // d0-d7 are using bank 0
setreg d2, 1 ; // d2 now mapped to bank 1
Changing the mapping would not destroy the original value. Eg
setreg d0-d7, 0
move.l #20, d0
setreg d0, 1
move.l #15, d0
setreg d0, 0 ; // d0 = 20
setreg d0, 1 ; // d0 = 15
To augment this, a "swap" operation, swapping the contents of the current dX with the equivalent dX register in another bank
swapreg d0, 3 ; // exchange current d0's value with bank #3 d0's value
Whilst not as flexible as a genuine 32 register file, it would remain object code compatible with older 680x0 and open interesting optimisations
I wish the 680x0 could be continued as a proper CPU (coldfire is interesting, but a more direct modern replacement for 68060 would be nice).
/dream off
the 68030 MMU OTOH is very well designed,
much better than the PPC MMU,
Why do you say that? The only gripe I have is that the 603 MMU needs some software support to handle table lookup, but the 604 and higher chips dont (AFAIK).
-
by Karlos on 2004/4/12 1:22:32
>Dude, your posts are huge
apologies in advance then!
>Let's see.
>So, there is a compiler for amithlon that generates x86 code that does automatic
>byte reversal for operands during load/save to memory, thus giving a "big endian"
>data model that the 680x0 model is compatible with.
ok, so it is big endian, I wasnt totally sure but from what you say later it is,
>This makes some sense. However, this also means that you have totally killed
>the benefits of a CPU capable of memory operands for the majority of normal code.
>This is because you have to (for anything bigger than a byte) load the operand
>from memory to a register, swap it from its "big" endian representation to
>little endian, perform an operation on it, reverse it again and pump it back
>out to memory.
exactly,
but Intels have huge caches (I think), so its not actually pumping it out
to memory but to the cache,
thus it will be a lot faster than you think,
I believe Amithlon does exactly this, and Amithlon users are
quite happy with its speed: its up to the mark of the more discerning
users whereas PPC isnt,
Note that the above compiler is for Amithlon, which proves I think that
Amithlon uses big endian emulation of RAM,
What does Sysinfo on Amithlon say the speed is??
>Sound familiar? It should. You turned your "complex addressing mode" x86 into a
>load/store architecture.
>
>Unfortunately, x86 doesn't have the register count to make load/store based code
>effective. In fact, it is especially bad at it since it was (like the 680x0)
>designed to be able to have memory operands for most instructions.
>
if it has 8 general purpose registers that is quite sufficient,
you may be underestimating compilers, see later,
>Conversely, load/store code is the domain of CPUs like the PPC, where all
>operations are on registers and to compensate for lack of memory based operands,
>you have plenty of registers.
PPC has toooo many registers, the people who designed it are clueless about
what compilers can do,
you need to look at the assembler output of SAS C which is very high quality
via omd or the output of gcc -O2 -S something.c -o something.s
before jumping to any conclusions,
to compute an expression with M terms you only need approx log_2(M) registers,
so to compute an expression with 64 terms eg
(x1 + x2/(x3 - x4*x5) /(x6+x7+ (x8-(x9/x10))) ................ x64
you only need approx 6 registers regardless of expression complexity,
you dont need 64 registers thats for sure,
IMO CPUs should be designed by s/w people, with h/w engineers to implement,
if you put engineers in charge you end up with interesting and slow CPUs,
IBM dont know how to design CPUs otherwise why did they originally use Intel
and now use Motorolas PPC specification
(I dont know how they did their Mainframes)
>Basically, if what you say is true, the compiler generates code that is
>"big endian" data format compatible at the expense of a large amount of code
>required to wrap fairly simple operations. In other words, speed is secondary
>to compatibility.
never make assumptions about speed, code that looks fast is often slow
and vice versa,
always remember that Amithlon does exactly this,
hands up anyone who thinks Amithlon is slow? (IYSWIM),
Note that in the assembler output the byte reversal happened at compile time,
so there was no run time overhead,
>Can you imagine what any half complicated C expression compiles to where variables
>are loaded from ram each time?
>Instead of being able to perform arithmetic on a register using a memory operand,
> you have to load the memory operand to another register, byte swap it etc.
your description of what happens is correct, but, I need to put you in the
picture of what compilers do:
variables are usually local variables, (unless its badly written code),
lets say you have a C function with 30 local variables,
a naive C compiler would implement that via 30 stack cells, not necessarily a
bad thing as the stack is almost guaranteed to be in the cache,
the byte reversal problem would happen,
However a sophisticated C compiler would implement those 30 local variables
by eg 4 registers so no byte reversal directly necessary,
a given variable say x would be implemented via several registers eg d0 d1 and d2,
conversely a given register say d2 would implement maybe 10 variables,
eg:
f( int x )
{
int y,z, t ;
y = 5 ; z = y + x ; t = z + 2 ;
return( z ) ;
}
in this the return is z = y + x = 5 + x ,
say x is a register d1
a good compiler would implement this as:
move.l d1,d0
add.l #5,d0
rts
2 registers implementing 4 variables,
the variable count is actually irrelevant to the compiler,
it is only interested in the data processing complexity which in
real programs is very low,
real progs tend to do things like:
if( strcmp( x->name , y->name )==0 ){ x->count++ ; thing_free( y ) ; return ; }
:data movement,
here y is absorbed by x and removed,
the maths is trivial nameley increase x->count by 1,
as explained earlier for an arbitrary complexity expression with 1024 terms
a compiler only needs approx 10 registers (it may be 9 or 11 registers),
many 1024 term expressions can be done with much fewer registers eg:
x1 + x2 + x3 +....+x1024 only needs 2 registers:
move x1,d0
move x2,d1
add d1,d0
move x3,d1
add d1,d0
move x4,d1
add d1,d0
.....
move x1024,d1
add d1,d0
(**A**)
(on 68k you may only need 1 register:
move x1,d0
add x2,d0
add x3,d0
add x4,d0
.......
In real code from real programs a lot of the time only 4 registers are necessary,
math expressions in real programs are usually very simple, most progs are
about data movement rather than maths,
with 32 registers you could do expressions with 4 billion terms which is
an impractical ability,
every register requires circuitry eg 64 flip flops and it requires "wires"
from these flip flops to the ALU (arithmetic and logic unit),
also the instruction decode circuitry becomes bigger: to decipher
register 30 = 11110 requires circuitry x4 & x3 & x2 & x1 & ~(x0)
4 AND-gates and 1 NOT-gate, so you will need 32 * 4 = 128 AND-gates,
and probably 32 * 4 / 2 = 64 NOT-gates, 192 components to decode 1 register,
PPC 3 address-code has *3* registers => 3 * 192 = 576 logic gates just
for instruction decode,
now add in the 64 * 32 flip flops for the registers = 2048 flip flops,
so that is already 2624 components,
are you still sure you want 32 registers? I am *certain* I dont!
space is very precious and limited,
this leads to a bigger CPU ie longer wires => higher latency => slower,
it also eats up instruction bits: 32 registers => 5 bits per register,
which doubles instruction size for 3-address PPC or MIPS,
>You also now see why the 1-address code model ain't really so hot at all (sorry,
>but it's true. x86 architecture comes straight from pocket calculator era,
>hence the "accumulator" register )
real compiler code uses exactly the accumulator concept see the code fragment
above: there is no alternative,
computing a mathematical expression is entirely an accumulator-process:
x = (y+z)*t ; load y, add z, mul t, store x,
also its always like this,
this is why accumulator CPUs will be very fast,
>Back onto 68K
>
>I disagree that the 680x0 architecture is flawed by its "odd" register behaviour,
>but I threw it in purely to show that endianness is even more perculiuar than
>many people think. Things are the way they are for a reason. It would be a flaw
>if it wasn't well
> documented that the registers behave that way and you just assumed they behaved
> the same way as memory
>
> The 68K has one of the nicest architectures IMHO. Too bad motorola canned it.
>The memory indirect addressing modes are a bit pointless, but other than that it
>is a fine design.
a lot of 68k is very well designed,
> GPUs are just ace for this type of oddness. I know ones which have little
>endian 16-bit words but big endian 32-bit words etc.
>
> Yeah I know the PPC allows big/little endian operation. That's easy for
>load/store based architectures and it's not alone in being able to do it.
>There are ARM cores with the same ability.
MIPS also,
> As for the supervisor stack thing:
>
> 1) are you sure that the SSP wasnt already remapped somewhere else in fast ram
>buy your 030?
yes, translation control register TC=$03ffffff,
bit 31 needs to be 1 to enable the MMU, so the MMU is off,
if I run
CPU fastrom
then TC=$80f17540, bit 31 is now 1 => MMU on,
> 2) the system doesnt exactly spend long in supervisor mode anyway.
>Most OS functions do the bulk of their work in user mode.
difficult to know this except by trying it and timing it,
all h/w interrupts and exceptions will be in supervisor mode,
anyway I timed it and that tells me your comment 2) is true,
> PS: Your asm code for the x86 $2018915346 is a decimal literal that is
>0x78563412 in hex.
>
> Thats your 0x12345678 with the bytes reversed. If your gcc compiler does create
>"big endian" data, it makes sense that integer literals would get statically
>converted in this fashion - the variable "x" now contains 0x78563412 as far as
>the x86 is concerned
>, but a 680x0 would see it as 0x12345678, which is what you are indending.
great!
you've solved this riddle, I couldnt see it,
when I see $ I immediately think that signifies hexadecimal,
have you figured out what the bswap statements are for?
-
Hi,
I'm sure I don't have the energy to reply to that point by point :-D
When I said the "big endian" data emulation model was slow, I meant compared to normal x86 code - not that it will be slow compared to a real 680x0 :-D
That is to say, compile 2 programs, one running in the normal x86 little endian memory access fashion, and once compiled to support a big endian data model. The little endian version will have much less work to do at runtime (eg swapping data when loading saving registers) and also the code will be optimal for it's "memory based operand" architecture.
As for RISC style load/store chips, lots of registers arent bad at all. Your main point is that you cant use them effectively and instructions increase in size etc.
On the usage front, I beg to differ - just study the PPC open ABI. Lots of important stuff (useful for the system) can stay in registers and you have lots of volatile registers for passing data to functions directly etc.
Stack based passing is only used there when there are more than 8 parameters to pass to a function and that's not often.
Also, the 3 operand instructions allow for lots of optimisations with clever compilers. Don't assume gcc is the smartest. I can quite assure you it isnt.
Ultimately, it comes down to a system where memory accesses for data are rare, since a lot of stuff is created in registers, passed arounf in registers and ultimately never ends up in memory unless that's its final destination.
This means memory/caches are hit less, stay valid for longer etc. and most memory accesses end up as bursts.
IBM dont know how to design CPUs otherwise why did they originally use Intel and now use Motorolas PPC specification
They don't? As I recall, Motorola used IBM's existing POWER (Performance Optimised With Enhanced RISC) architecture to create a desktop CPU, the PowerPC (with Apple as the cheif customer). It was basically a partnership in which IBM provided the architecture, Motorola provided the fabrication processes and Apple sold them :-)
IBM currently make by far the best implementations of the PowerPC architecture, surpassing motorola by quite a margin.
On the design complexity front, the large register count is not a big deal. You do realise that modern x86 cores (since as far back as the Pentium2) use dozens of registers in shadow register files? Internally, the architecture is totally different from the code you see in your assembler. Incoming x86 code is decomposed into smaller RISC like operations. The core executes these operations and makes use of a very large number of registers in the process.
Hence the objections you raise aren't really valid because x86 and PPC both use multi-operand instructions with lots of registers. It's just that you see it directly on the PPC and don't on the x86 ;-)
Finally, I dunno what bswap are for, but I expect they probably aren't endian conversion operations. I'm not too hot on x86 assembler :-)
-edit-
Anyhow, to summarise, architectual comparisons are getting a bit off topic. Alas, if you believe you can compile AROS with this "big endian" dataformat GCC with the intention of adding a 680x0 emulation, I say go for it - it would be an interesting thing to see :-)
The trouble is, stimulating conversation though it has been, I genuinely don't feel I'm helping you get any closer that goal, so I'll settle for wishing you luck :-D
-
exactly, but Intels have huge caches (I think), so its not actually pumping it out
to memory but to the cache, thus it will be a lot faster than you think,
The problem is not with memory accesses (x86 generally have the most efficient caches in the computing world), the problem is that code goes from (stupid example):
mov eax, [ebx+myOffset] ; dependency on ebx
add eax, ecx ; dependency on the above load+ecx
to:
mov eax, [ebx+myOffset] ; dependency on ebx
bswap eax ; dependency on above load
add eax, ecx ; dependency on bswap+ecx
For a modern OOO processor the most important compiler optimization is to make the dependency chains as short as possible, bswaps lengthens the dependency chains and so makes the code generally slower.
if it has 8 general purpose registers that is quite sufficient,
you may be underestimating compilers, see later,
No you are. Without enough "native" registers the compiler can't really do a number of powerful optimizations such as loop unrolling, software pipelining, loop fusion and more. That is (as with all thing in life) not completly true, x86 compilers can use those optimizations for some cases but not for more interresting problems.
PPC has toooo many registers, the people who designed it are clueless about
what compilers can do, ...
What?!? RISC where designed to make it possible to get a more effective hardware-software interaction and one of the things that makes it better is more registers! You are really making yourself sounding clueless...
to compute an expression with M terms you only need approx log_2(M) registers,
No you don't need any (programmer visible) registers at all. LIFO-4-life.
IBM dont know how to design CPUs otherwise why did they originally use Intel
and now use Motorolas PPC specification
(I dont know how they did their Mainframes)
Really... It is now clear that you have absolutely no f*c*ing clue about this area, and still you want to expose your ignorance?
IBM invented many things that now is used in processors all over the world, but they have no clue right?
Their research where what made RISC a possibility, their Power line of processors provided the base for the PPC architecture which clearly shows that they are clueless.
How they did their mainframes? They designed and implemented an architecture that inspired most other computer manufacturers and is still after many many years top of the line in it's field. But of course they don't know how to design CPUs...
a good compiler would implement this as:
move.l d1,d0
add.l #5,d0
rts
2 registers implementing 4 variables,
No a good compiler would inline that code...
many 1024 term expressions can be done with much fewer registers eg:
x1 + x2 + x3 +....+x1024 only needs 2 registers:
move x1,d0
move x2,d1
add d1,d0
move x3,d1
add d1,d0
move x4,d1
add d1,d0
.....
move x1024,d1
add d1,d0
And suddenly your processor is serialized! The last add will be dependent on the preceding 2047 instructions, a better compiler would make use of the superscalar nature of the processor and allow the hardware to parallellize it.
In real code from real programs a lot of the time only 4 registers are necessary,
Yes completly true.
with 32 registers you could do expressions with 4 billion terms which is
an impractical ability,
And yet again your ignorance shows. The reason for having many registers are that one can generate more efficient code, I have sometimes been forced to use the ESP (the x86 stack pointer register) in some innerloops to get satisfactory results as the 7 "free" registers where not enough. 16 registers really simplifies the code generation (for both ASM-programmers and compilers) and 32 is even better.
Let's see... The year is 2004, most manufacturers are now beginning to target 90nm processes. This fact combines with the fact that register files are compact (==short wires). When we then add the fact that modern processors already have >80registers (for renaming), that decode and scheduling parts of the processors are much more complex and larger than a tiny register file it really seem redicolous to complain about it. And with more registers we can optimize the code better and thus get faster execution, do you still complain?
real compiler code uses exactly the accumulator concept see the code fragment
above: there is no alternative,
computing a mathematical expression is entirely an accumulator-process:
x = (y+z)*t ; load y, add z, mul t, store x,
also its always like this,
this is why accumulator CPUs will be very fast,
LOL!
-
. . . . . :python:
-
Getting AROS to boot directly on an A1 sounds a very high priority project, so if it hasnt been completed I may join that project, it also sounds very interesting,
I understand AROS already runs above Linux on A1 so AROS is there already but not the way many people want,
It would certainly be a great thing to have AROS running Nativly on the A1.
The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus, who is resolving some stack issues, and attempting to get the Graphics drivers to work.
if you compile AROS with big endian Intel gcc then you can have seamless 68k + x86 AROS integration using some variant of my suggestion,
read + execute exceptions would toggle between emulated and nonemulated instructions,
That's true, if we treated all memory access in AROS as Big Endien we could have the same 68k emulation method as OS4 and MorphOS use. But it has been decided that the performance penalty of running a little Endien CPU with Big Endian data was to significant (something like 30% penalty) that it was not worth it.
Besides if we use an integrated UAE we also get Hardware compatibility and improved stability so it's a benefit all round.
Would there be any point in creating your own AROS PPC platform?
AROS IS the platform, what hardware you choose to run it on is up to you. :-)
Be that a Mac, a PC, a Pegasos, an A1 or a washing machine... it's up to you.
>The Default Compiler is gcc.
this is the deciding factor,
which versions?
I hope you have gcc2.95.3-4 even though its not the most current,
is it a specifically AROS gcc or do you reuse generic ones?
Have you got 68k hosted cross compiler gcc's (PPC , Intel) for AROS?
To compile AROS you have to use the latest gcc (3.x.x). The AROS native version of gcc is the latest.
gcc supports the x86, the PPC and the 68k. this was a deciding factor in choosing it. Since AROS can be compiled for all of those CPUs.
you realise that gcc is also an assembler, the moment a platform has gcc
it automatically has an assembler:
Of course, other wise gcc wouldn't be able to output executable code. But the AROS distribution also includes the x86 assembler NASM, for those that want to just ply with x86 asm in AROS.
It should be noted however, that due to the cross platform nature of AROS, the use of ASM is actively discouraged. One should use C at all times.
The only exception is in some low level systems (noteably the exec.library) which need to access CPU specific features.
so eg commercial AROS IBrowse can be closed source?
Yes of course software can be closed source. But it would then be up to the software vendor to provide support for the different CPU versions of their software (ie 68k, PPC and x86). This can lead to the situation where x86 AROS users get a program that PPC AROS users don't get, and Vice Versa.
iospirit announced they have abandoned OS4 development,
there was a link to this from AmigaWorld.net at the time of the
KMOS takeover,
ask iospirit if they will recompile + sell IBrowse to AROS,
they have nothing to lose by doing this,
they already have an up and running website for selling IBrowse,
If there is demand for it, it will happen. Remember that AROS does not at this time have a fully functional TCP/IP stack. So general networking software is not a priority.
-
@Megol,
-----------
-----------
in the time it would take to reply to your time-wasting I could
write some significant code, so I wont even give you the time of day,
buy your own watch,
you are yet another person who confuses h/w architecture with s/w,
oh well I suppose if you throw enough buzz words into one sentence
maybe it will get you somewhere, anything is possible,
sorry! byee!
@Karlos
>When I said the "big endian" data emulation model was slow,
>I meant compared to normal x86 code - not that it will be slow compared
>to a real 680x0
fair enough,
it will be trickier for 68k emulation to share datastructures with the
host AROS,
:you could run it in its own screenspace without problems,
>becomes slow though because the byte swapping will have to
>
>That is to say, compile 2 programs, one running in the normal x86 little
>endian memory access fashion, and once compiled to support a big endian data
>model. The little endian version will have much less work to do at runtime
>(eg swapping data when loading a
>saving registers) and also the code will be optimal for it's
>"memory based operand" architecture.
probably true, but you need to actually generate both versions and time it
before concluding things,
so many times I have done analysis comparable to yours and then spent
an afternoon "speeding" up the code: but when I run it the original "slow" code
is faster,
nowadays I always backup code fully before attempting "speed ups",
the big endian will certainly be slower, but will it be significantly slower?
eg in the gcc generated x86 asm fragment there was no overhead as the
reversal happened at compile time,
>As for RISC style load/store chips, lots of registers arent bad at all.
>Your main point is that you cant use them effectively and instructions
>increase in size etc.
>
>On the usage front, I beg to differ - just study the PPC open ABI.
> Lots of important stuff (useful for the system) can stay in registers and you
>have lots of volatile registers for passing data to functions directly etc.
you only need 1 register to store the entire system stuff,
register r9 = pointer to struct { void *this, *that, *theother, *execbase, ... } ;
you want execbase in r3?:
move.l 12(r9),r3
1 asm instruction, nothing really,
(I am not talking here about CPU registers eg SRP and TC on 68030 which are
not general purpose registers),
on AmigaOS its quite practical to have no system stuff at all in registers,
(ok the library base goes into a6, but thats it),
all other system stuff can be obtained in one or 2 asm statements
on the rare occasions its needed,
give me a list of specific system things you want in individual registers?
>Stack based passing is only used there when there are more than
>8 parameters to pass to a function and that's not often.
register arguments dont necessarily speed things up:
the registers need to be backed up to the stack and later restored
(==2 extra stack references), so its only useful for heavily used registers,
but if a register is heavily used the overhead for backing up the original
contents becomes irrelevant
so actually stack based arguments are more practical and totally portable,
>Also, the 3 operand instructions allow for lots of optimisations
>with clever compilers. Don't assume gcc is the smartest.
>I can quite assure you it isnt.
SAS C is better than gcc,
3 operand optimisations are a false economy:
to do d0 + d1 + d2 + d3 via 3 address code and lots of registers:
add.l d0,d1,d4
add.l d2,d3,d5
add.l d4,d5,d6
is 12 bytes of instructions and has a register cost of 3 (d4,d5,d6),
load d0
add d1
add d2
add d3
is a mere 4 bytes of instruction and has 0 register cost,
(register cost == 1 if you count the accumlator register),
that is an efficiency improvement of 3 and 3 respectively,
I do know what I am talking about despite Megols confused attempt,
I think I will argue my point till I am hoarse,
so my time is better spent coding which I am doing right now:
I am currently "improving" my 68k AmigaOS,
after todays posts I will be spending several hours coding to
modernise 68k AmigaOS, this is why I dont have the 1/2 hour to reply to Megol:
priorities,
your comments are constructive so I give it the 1/2 hour,
>Ultimately, it comes down to a system where memory accesses for
>data are rare, since a lot of stuff is created in registers,
>passed arounf in registers and ultimately never ends up in memory unless
>that's its final destination.
well written code will be implemented with minimal memory references,
often the major overhead is h/w i/o eg disks,
>This means memory/caches are hit less, stay valid for longer etc. and
>most memory accesses end up as bursts.
>>IBM dont know how to design CPUs otherwise why did they
>>originally use Intel and now use Motorolas PPC specification
>They don't? As I recall, Motorola used IBM's existing POWER
>(Performance Optimised With Enhanced RISC) architecture to create a desktop CPU,
>the PowerPC (with Apple as the cheif customer).
>It was basically a partnership in which IBM provided the architectua
>e, Motorola provided the fabrication processes and Apple sold them
you are right, Power is IBM's, for some reason I thought it was Motorola,
my point is valid though because Intel is faster,
"Performance Optimised With Enhanced RISC And Nowhere Near As Quick As Intel"
POWERANNAQAI
IBM good Intel bad Motorola hopeless,
>IBM currently make by far the best implementations of the PowerPC architecture,
>surpassing motorola by quite a margin.
true, and Intel is faster,
>On the design complexity front, the large register count is not a big deal.
>You do realise that modern x86 cores (since as far back as the Pentium2)
>use dozens of registers in shadow register files?
>Internally, the architecture is totally different from tha
> code you see in your assembler. Incoming x86 code is decomposed into smaller
>RISC like operations. The core executes these operations and makes use of a
>very large number of registers in the process.
but hidden registers are better than visible ones,
I would prefer to have an ultra rapid stack cache rather than lots of registers,
have 32 * 64 bytes of stack cache,
>Hence the objections you raise aren't really valid because x86 and PPC
>both use multi-operand instructions with lots of registers.
>It's just that you see it directly on the PPC and don't on the x86
but then your objections to x86 also arent valid because your criticism
was that x86 has to act on ram operands and now you tell me it doesnt,
>Finally, I dunno what bswap are for, but I expect they probably aren't
>endian conversion operations. I'm not too hot on x86 assembler
ok, I wont ask Megol because he's trouble,
>The trouble is, stimulating conversation though it has been,
>I genuinely don't feel I'm helping you get any closer that goal,
>so I'll settle for wishing you luck
fine,
-
Hi,
but then your objections to x86 also arent valid because your criticism was that x86 has to act on ram operands and now you tell me it doesnt
No, that's not quite what I said. I meant the design paragdim of x86, from the programmer perspective, is that it can use memory direct operands for x86 level instructions, just like 680x0 does. So you do an add operation of a memory opetand onto a register or vice versa etc.
It doesn't *have* to use menory operands (adding register to register, for example is fine), but it doens't have a great deal of registers to spare, so it makes sense to use memory operands.
Up to the Pentium, this is how the core worked, but it was badly falling behind newer RISC architectures in terms of performance. The chip designers could see the advantage of load/store based superscalar CPUs, but couldn't throw away their existing object code compatibility.
So they did pretty much what motorola also did with the 68060, and later cores simply used a lower level RISC style code that incoming x86 "micro-op" instructions are dissasembled into.
So, from your perspective, as a programmer, the x86 does use memory based operands, and you can add a memory operand to your accumulator register.
Now, in reality, that add instruction, during execution gets decomposed into a micro-op load operation to fetch the ram operand, an add, a register file write and so on.
If you look at what x86 code is translated into at micro-op level, you see something very much more like your PPC style code, with lots of register to register operations, many registers and load/store for memory access.
However, as a programmer, you are not exposed to this level, but it does exist. This is partly why most chip designers simply shrug off RISC v CISC comparisions these days, since deep down most modern CPUs are virtually the same.
Regarding 32 registers on PPC, I wrote plenty of code that makes use of it. You are incorrect about the implicit register backup required on the stack for register based calls because the PPC open ABI defines those registers as volatile. Just like you never need to worry about saving d0/d1/a0/a1 for most 680x0 stuff (and similarly cannot assume they survive a function call), roughly half the registers of the PPC ABI are volatile and can be used for argument passing and temporary local variables.
I wrote various matrix multiplication code for transforms on ppc (some of the only hand asm I wrote) that is extremely fast since the entire transformation matrix' terms remain in registers for any number of vertices processed. 12 floats defining the buisness end of the matrix are held in volatile registers and you even get single cycle 4-operand multiply-add (register*register+register -> register) operations to help when evaluating the matrix * vector stuff.
Literally, throught the loop the only stuff accessing memory was the instruction stream, incoming vertices and outgoing transformed vertieces. And the loop, of course pretty much stays in the cache :-D
There is no way I could get say the 680x0 to get anywhere near the code efficiency of it.
I know you don't see large register files as at all useful, but if you look at the way present x86 processors actually work inside and the way they are going with the 64-bit designs (IIRC, IA64 has 256 registers) I think you might be in a minority.
-
@bloodline
>>Getting AROS to boot directly on an A1 sounds a very high priority project, so if it hasnt been completed I may join that project, it also sounds very interesting,
>>I understand AROS already runs above Linux on A1 so AROS is there already but not the way many people want,
>>It would certainly be a great thing to have AROS running Nativly on the A1.
>The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus,
>who is resolving some stack issues, and attempting to get the Graphics drivers
>to work.
for me the word Linux is underlined here,
can this Linux work be reused in a directly A1 booting AROS?
IMO the future of the Amiga will be entirely powered by 3rd party developers,
I still havent decided between A1 vs PC, I have decided on AROS though!
I feel if I buy a PC I am a turncoat or traitor, however if AROS directly
boots ie no Windows and its not Intel then maybe thats better than
using IBM PPC on the A1?
Its strange that IBM are now "good" and Intel are "bad",
Having read the book "Big Blue" IMO IBM are anything but good,
and there is no basis for thinking Intel are "bad": Intel never
did anything "bad",
MS OTOH IMO are bad,
Now PPC AROS has a very clean boot environment: portable + standard
via Openfirmware and eventually UBoot too,
How clean is PC AROS boot?
(the cleanness of the PPC AROS boot appeals to me),
Re PC AROS if I have understood you:
1. I buy a PC,
2. I download AROS,
3. I directly boot AROS?
4. I run UAE above AROS for full 68k compatibilty?
Is this correct?
In the UK have you any tips about buying a new PC?
Are the places like PCWorld, Comet, Staples, Dixons a good place to try
or should I go to specialist shops eg from computer mag adverts?
>>If you compile AROS with big endian Intel gcc then you can have seamless 68k + x86
>> AROS integration using some variant of my suggestion,
>>read + execute exceptions would toggle between emulated and nonemulated instructions,
>That's true, if we treated all memory access in AROS as Big Endien
>we could have the same 68k emulation method as OS4 and MorphOS use.
>But it has been decided that the performance penalty of running
>a little Endien CPU with Big Endian data was to significant
>(something like 30% penalty) that it was not worth it.
30% is nothing,
if a car goes by at 70mph and 10 minutes later another car goes by at 100mph
would you know the difference (I am talking about perceptions here),
(70mph being 30% slower than 100mph)
can you go both ways: ie have Big endian PC AROS and Little endian PC AROS,
>Besides if we use an integrated UAE we also get Hardware compatibility
>and improved stability so it's a benefit all round.
can you integrate UAE at the RAM level with little endian RAM?
if a 68k program accesses OS data structures ints and words at the byte level
or bytes at the word level the OS will get mangled
most programs wont do this so maybe you dont lose too much,
>>Would there be any point in creating your own AROS PPC platform?
>AROS IS the platform, what hardware you choose to run it on is up to you.
>Be that a Mac, a PC, a Pegasos, an A1 or a washing machine... it's up to you.
!
ok, the answer is no!
everyone says its not a big deal that Eyetech created the A1,
I wondered whether they could prove this by doing their own one,
>>>The Default Compiler is gcc.
>>this is the deciding factor,
>>which versions?
>>I hope you have gcc2.95.3-4 even though its not the most current,
>>is it a specifically AROS gcc or do you reuse generic ones?
>>Have you got 68k hosted cross compiler gcc's (PPC , Intel) for AROS?
>To compile AROS you have to use the latest gcc (3.x.x).
>The AROS native version of gcc is the latest.
do you keep the earlier ones?
>gcc supports the x86, the PPC and the 68k.
>this was a deciding factor in choosing it.
>Since AROS can be compiled for all of those CPUs.
gcc supports all modern CPUs in existence more or less,
certainly all CPUs that run Unix and Linux: there are many,
if you dont have gcc you have to have a very good excuse,
no other programs are compulsory though,
>>you realise that gcc is also an assembler, the moment a platform has gcc
>>it automatically has an assembler:
>Of course, other wise gcc wouldn't be able to output executable code.
not what I meant,
some compilers only have an internal assembler,
some Modula 3 compilers dont even have an internal assembler:
they convert Modula 3 progs to c which is then fed to gcc,
A Basic interpreter such as AmigaBasic I think doesnt have an assembler,
you can write + run progs with it though,
IMO 68k hosted cross compilers are very important,
imagine you have say:
big endian PC AROS, little endian PC AROS, Openfirmware AROS, UBoot AROS,
68k AROS,
ie 5 variants of AROS,
that would require 25 cross compilers to get code from any one AROS to any
other,
however if you have 68k hosted cross compilers then you only need 5
68k-hosted cross compilers,
this would greatly reduce the compiler maintainance overhead,
I think you need 2 68k hosted cross compiler gcc's
for PPC and PC AROS,
:people on all Amiga variants could then start generating AROS native progs,
>But the AROS distribution also includes the x86 assembler NASM,
>for those that want to just ply with x86 asm in AROS.
a real assembler is useful because it will conform with
3rd party assembler textbooks
:gcc assembler *doesnt* conform, it is totally nonstandard,
for me it has become my default 68k assembler though,
>It should be noted however, that due to the cross platform nature of AROS,
>the use of ASM is actively discouraged. One should use C at all times.
>The only exception is in some low level systems (noteably the exec.library)
>which need to access CPU specific features.
I agree with the policy, however some things can only be done via assembler,
the AROS developers themselves probably need to use asm
to implement low level things,
also to really understand a machine you need to at least understand assembler,
there are a lot of programmers who will only code in assembler,
give them an assembler and they will write fantastic programs,
and they will *never* use C or any other high level language,
you were talking about demo coders, you may need to provide full docs on
coding entirely on assembler on specific platforms if you want
fantastic demos written,
These demos will be unportable but fantastic, the demo coders soon move on
to writing games,
there is a real buzz from directly controlling hardware from asm statements,
switching supervisor stack to fastram was really satisfying even though it
just amounts to:
movea.l new_stackpointer,a7
but done in supervisor mode, (its more complicated because you have to
also copy the exception stack frame over, I used 11 asm statements to do it
ending in rte,)
you cannot get this buzz from C. You are the controller with asm, with C
the controller is the compiler and the OS,
when you control via asm you start to develop a total
understanding of the system,
With the a500 and a600 there were literally *millions* of users who *never*
even used Workbench, they booted games directly,
this may be why games consoles are so popular,
Now you can also write C demos but its a totally different mindset,
C coding tends to lead to system programs and apps,
I am not into apps myself (except possibly developer apps) as
apps are either too entertaining (paint and songs) or too office-ish,
I want serious fun, not paint-cans and doh-ray-mee and accounts,
(company statistician speaking, pencil behind ear,),
assembler coding leads to games: creatures + music + graphics,
3D games probably needs C, though maybe just the engine needs to be done in C?
2D games is an inexhaustible genre,
my favourites are Lemmings, boulderdash, tetris,
(all of which could've been done in C),
good games are not actually about impressive graphics but about
engaging your mind in an interesting way,
IMO the best games are 2D, 3D games look impressive as an onlooker
but to actually play I find them a total disappointment: why not just do
something in the real world if you want 3D eg play basketball as a hobby,
learn to drive a real car, driving an arcade car is so sad, please grow up,
if you are going to be sad be sad properly!
computer 3D always sucks because you can literally see the computer slow down
and wince whenever something computationally complex happens,
:the real world never slows down (except in the circus in that film "Big Fish"),
if I could slow down the real world, I would smash a whole column of plates
and utilise the slowdown somehow,
>>so eg commercial AROS IBrowse can be closed source?
>Yes of course software can be closed source.
good, if it wasnt I would say "very interesting but no thank you",
industry is all about closed source design,
closed source => competition + money,
open source => bloat,
open source can be lean and mean but then it gets raided,
if you spend 1 month generating some nightmare cutting edge algorithms for
some API you may not want 3rd party developers to raid your work,
lets say you spent 1 year creating a cutting edge 3D graphics engine,
you could make some serious money from this, not just games:
you could sell it to film companies and make 7 digits of money,
what happens on gnu is developers cover their tracks by coating the
work with impenetrable layers of bloat,
probably same is true of Linux,
Amiga.org is closed source isnt it?
ISTR Mike Bouma paid a fat cheque for AmigaWorld.net, quite right too,
he had the money they had the IP, they made an exchange,
now he has the site, they have the money, everyones happy,
Mike really wanted amiga.org, had amiga.org been open source he would
have just downloaded it and created his own site to compete with amiga.org,
(this is public knowledge based on public discussions between Mike and Wayne),
I think Mike wasnt prepared to pay for Waynes asking price,
maybe Wayne should have rented it out!
(or rented out some forums),
>But it would then be up to the software vendor to provide support for
>the different CPU versions of their software (ie 68k, PPC and x86).
>This can lead to the situation where x86 AROS users get a program that PPC
> AROS users don't get, and Vice Versa.
but this is better than no program at all!
Shelves of stuff will only appear if its closed source,
a lot of www.aminet is closed source,
Note that if a 68k version is also done then it reaches all platforms via UAE,
so its just the native compile that would be lacking,
:this is a good reason for having a fully implemented 68k AROS,
>>iospirit announced they have abandoned OS4 development,
>>there was a link to this from AmigaWorld.net at the time of the
>> KMOS takeover,
>>
>>
>>ask iospirit if they will recompile + sell IBrowse to AROS,
>>
>>
>> they have nothing to lose by doing this,
>> they already have an up and running website for selling IBrowse,
>If there is demand for it, it will happen.
>Remember that AROS does not at this time have a fully functional TCP/IP stack.
>So general networking software is not a priority.
If AROS has fully integrated 68k compatibility you could use a
3rd party 68k TCP/IP stack until you have your own open source one written,
:you mustnt use Amiga co. OS binaries, but you are free to use 3rd party
68k OS binaries + libraries eg from www.aminet,
can you get the 3rd party TCP/IP stack people to recompile their code for you?
presumably its in OS3.1 c??
IBrowse and other commercial developers may not be aware that
closed source is permitted,
I didnt know and assumed it wasnt permitted except via 68k and UAE,
in fact I was dreading your reply to the question, luckily the answer is
exactly what I want,
you may need to target some publicity at potential commercial developers
about AROS allowing closed source + commercial programs,
AROS publicity tends to tell us that AROS is an open source reimplementation
of OS3.1, the phrase "closed source" is never mentioned,
to this day I dont even know if closed source commercial binaries
are allowed on Linux,
-
>>It would certainly be a great thing to have AROS running Nativly on the A1.
>The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus,
>who is resolving some stack issues, and attempting to get the Graphics drivers
>to work.
for me the word Linux is underlined here,
can this Linux work be reused in a directly A1 booting AROS?
Yes, when you think of AROS Hosted, think of Linux as a Hardware abstraction layer. Running AROS on Linux can be thought of as the same as running AOS3.1 in UAE.
While AROS is running on Linux one can work out all the bugs and issues. Then you can add the Firmware boot code and boot AROS on it's own.
It should be noteed at 99.9% of the AROS source code is cross platform, it's just the CPU specific/ASM stuff that needs reworking.
I feel if I buy a PC I am a turncoat or traitor, however if AROS directly
boots ie no Windows and its not Intel then maybe thats better than
using IBM PPC on the A1?
Its strange that IBM are now "good" and Intel are "bad",
Having read the book "Big Blue" IMO IBM are anything but good,
and there is no basis for thinking Intel are "bad": Intel never
did anything "bad",
MS OTOH IMO are bad,
To be honest, the "good"/"bad" lables are a redundant conceptual model. Nothing is good or bad, things fall into two categories, "Usefull" and "Useless" with respect to your requirements.
Windows for example is "Useless" if I want to use an OS that looks and feels the way I want an OS to look and feel, but it is "Useful" is I want to run a certain peice of software.
When choosing hardware you must first consider what your requirements are, then choose what is useful and at the cheapest price. Ignore religious/political issues like "brand" and "make", these things are unimportant when it comes to technology.
How clean is PC AROS boot?
(the cleanness of the PPC AROS boot appeals to me),
Re PC AROS if I have understood you:
1. I buy a PC,
2. I download AROS,
3. I directly boot AROS?
4. I run UAE above AROS for full 68k compatibilty?
Is this correct?
Yes, just download the AROS CD image, burn that to a CD-ROM, then put that in the CD drive, turn the PC on... AROS will boot and run by itself.
You will presented with an early startup menu allowing you to select certain hardware options (good news if you have a Nvidia gfx card), or you can ignore them and it will boot after 5 seconds.
In the UK have you any tips about buying a new PC?
Are the places like PCWorld, Comet, Staples, Dixons a good place to try
or should I go to specialist shops eg from computer mag adverts?
I would build the machine myself. There are plenty of shorps that sell PC parts for good prices. http://www.dabs.com is a great UK website selling top quality parts for a low price.
Don't forget that Black Troll sell complete PC's with AROS already installed for around £160 or so (depending upon the exchange rate).
High Street stores will rip you off.
>That's true, if we treated all memory access in AROS as Big Endien
>we could have the same 68k emulation method as OS4 and MorphOS use.
>But it has been decided that the performance penalty of running
>a little Endien CPU with Big Endian data was to significant
>(something like 30% penalty) that it was not worth it.
30% is nothing,
if a car goes by at 70mph and 10 minutes later another car goes by at 100mph
would you know the difference (I am talking about perceptions here),
(70mph being 30% slower than 100mph)
can you go both ways: ie have Big endian PC AROS and Little endian PC AROS,
30% is far too much. When running AROS on a 3.066Ghz CPU, are you really happy to write off nearly a whole 1Ghz (919.8Mhz) of performance?
There is no point to cripple a CPU, AROS runs using the Native byte order of the CPU, thus it is big endien on 68k and PPC and little Endien on the x86.
You could build a Big Endien AROS for the x86 but that would be incompatible with the faster Little Endian one.
Besides if we use an integrated UAE we also get Hardware compatibility
>and improved stability so it's a benefit all round.
can you integrate UAE at the RAM level with little endian RAM?
if a 68k program accesses OS data structures ints and words at the byte level
or bytes at the word level the OS will get mangled
most programs wont do this so maybe you dont lose too much,
The Idea for the integrated UAE is so that the 68k and the x86 do not share Data structures. But instead allow the two system to synchronise their data. This will allow 68k programs to run in the same environment as the x86 programs. The only down side is that 68k programs will not be able to call x86 functions and vice versa. This could be possible, but probably not worth it. The UAE Emulator will be running a 68k version of AROS (specially designed to synchronise with the x86 version).
everyone says its not a big deal that Eyetech created the A1, I wondered whether they could prove this by doing their own one,
Anyone is able to sell Terrons. I could put a little sticker on it if you like and sell it to you.
people on all Amiga variants could then start generating AROS native progs,
Since AROS is source code compatible with AmigaOS, it is easy to write your program on your A1200 in C... and then take that source code to An AROS machine and recompile for whatever CPU that is running.
gcc has a cross compiler, there is no probelm generating code for any CPU from any CPU, providing you have the includes of course.
computer 3D always sucks because you can literally see the computer slow down
and wince whenever something computationally complex happens,
I've guess you've not used a new 3D card then. I have yet to write a program that causes my Radeon 9000 to slow down even with over 10000 objects (using the DX7 interface).
Amiga.org is closed source isnt it?
No. Both Amiga.org and Amigaworld.net use xoops which is a great example of opensource software. Aros-Exec.org also uses xoops.
Note that if a 68k version is also done then it reaches all platforms via UAE,
so its just the native compile that would be lacking,
:this is a good reason for having a fully implemented 68k AROS,
We need the 68k AROS for the integrated UAE Emulator idea. I also want to run AROS on my A1200. We do have a working 68k AROS, but it needs to be adapted to boot the Amgia Hardwre. At the moment it only boots the Palm PDA.
If AROS has fully integrated 68k compatibility you could use a
3rd party 68k TCP/IP stack until you have your own open source one written,
That would require a Big endien AROS, something that we have already decided is a bad idea on the x86.
AROS will not use a 3rd party TCP/IP stack. When AROS gets a TCP/IP stack it will be fully integrated and designed as part of AROS, rather than an add-on.
you may need to target some publicity at potential commercial developers
about AROS allowing closed source + commercial programs,
AROS publicity tends to tell us that AROS is an open source reimplementation
of OS3.1, the phrase "closed source" is never mentioned,
AROS is a word of mouth effort, there's no budget for promotion :-)
Well AROS is an Open source reimplementation of OS3.1 :-)
to this day I dont even know if closed source commercial binaries are allowed on Linux,
It depends. If you link to a GPL library or use any GPL code, then your software automatically becomes GPL.
If you link to an LGPL library then you program is not GPL or LGPL.
If you use any BSD code then that does does not cause your code to be BSD.
Simply check the licence of any software you are using to find out what you can and can't do.
AROS is covered by the APL, which is similar to LGPL. IF you use AROS source only the code that you use must remain Opensource. The rest of your program is yours.
Licence issues are very complex.
-
@Bloodline:
hi!
"An A.orger who wants inline 68k emulation in x86 AROS "
that's me! :-)
Bernd Meyer replied some of my posts in ANN, and he thinks that using the memory as I described (using the memory in reverse order for the 68k memory allocated areas like in the Mac emu Executor) may work to a certain degree but may cause problems like reversed screens etc... so a better approach should be found
-
Crumb wrote:
@Bloodline:
hi!
"An A.orger who wants inline 68k emulation in x86 AROS "
that's me! :-)
Bernd Meyer replied some of my posts in ANN, and he thinks that using the memory as I described (using the memory in reverse order for the 68k memory allocated areas like in the Mac emu Executor) may work to a certain degree but may cause problems like reversed screens etc... so a better approach should be found
Then have a go and get a test program up and running, and we can test it and see if we can work out any bugs.
-
Crumb wrote:
Bernd Meyer replied some of my posts in ANN, and he thinks that using the memory as I described (using the memory in reverse order for the 68k memory allocated areas like in the Mac emu Executor) may work to a certain degree but may cause problems like reversed screens etc... so a better approach should be found
Just thinking about this.
Suppose your Task structure is a little different for any thread currently emulating 68K code, allowing the OS to see that this thread expects big endian memory.
Libraries can then detect if the caller is expecting big endian data or not. So in theory you could allow calls to the OS from the 680x0 side because they can check for it and respond accordingly.
Alternatively, you can have stub libraries for "big endian data access" to normal libraries and whenever a emulated 680x0 thread opens a library, it really gets the stub.
As for that screen issue.
Now, your 680x0 emulation opens a screen by ultimately calling the x86 native OS code. The data format returned should be in whatever format makes most sense for the x86, since most of the rendering will be done by the OS anyway.
If the user (under 680x0 emulation) wants to render into the screen directly, via LockBitMapTags() or whatever, the data format returned for the locked bitmap will be eg RGB16PC or BGRA or whatever other absolute format. Most likely it will always be a "little endian" format.
Since locking bitmaps for direct access *must* care for any format returned anyway, I don't see a problem for the 680x0, other than the fact it will be performing an unneeded byteswap in 680x0 code (which is then byteswapped again in the emulation :-D ) so the relative perfomance will be down a little.
If you think about it, lots of existing amiga gfx cards use little endian data modes that any code doing direct access to has to take care of, I don't see this as being any different.
-
by Karlos on 2004/4/14 4:56:20
Hi,
Quote:
>>but then your objections to x86 also arent valid because your criticism was that x86 has to act on ram operands and now you tell me it doesnt
/*
No, that's not quite what I said. I meant the design paragdim of x86,
from the programmer perspective, is that it can use memory direct operands for
x86 level instructions, just like 680x0 does. So you do an add operation of a
memory opetand onto a registem
or vice versa etc.
It doesn't *have* to use menory operands (adding register to register,
for example is fine), but it doens't have a great deal of registers to spare,
so it makes sense to use memory operands.
Up to the Pentium, this is how the core worked, but it was badly falling
behind newer RISC architectures in terms of performance.
The chip designers could see the advantage of load/store based superscalar CPUs,
but couldn't throw away their existing objecm
code compatibility.
So they did pretty much what motorola also did with the 68060, and later
cores simply used a lower level RISC style code that incoming x86 "micro-op"
instructions are dissasembled into.
So, from your perspective, as a programmer, the x86 does use memory based
operands, and you can add a memory operand to your accumulator register.
*/
effectively you are saying it has an internal RISC emulator of the CISC code,
/*
Now, in reality, that add instruction, during execution gets decomposed into a
micro-op load operation to fetch the ram operand, an add, a register file
write and so on.
If you look at what x86 code is translated into at micro-op level, you see
something very much more like your PPC style code, with lots of register to
register operations, many registers and load/store for memory access.
*/
ok, but this may be exactly why Intel is faster than PPC,
you are regarding this mechanism as worse than PPC,
but I think it may be better than PPC,
I have to talk in terms of 68k which I understand, so pretend we have a
68k version of Intels mechanism ie a PPC inner core interpreting 68k binary,
the advantage is that the binary is typically twice as small which means we
double the instruction access speed,
that inner RISC core when it emulates will be using some inner ultra fast RAM,
ie not external real RAM, thus we combine the small code advantage of CISC
with the fast code execution of RISC,
if a 68k + PPC hybrid were done ie 68k binaries with inner PPC interpretation
of the 68k as with Intel then I think this could be considerably faster
than PPC,
/*
However, as a programmer, you are not exposed to this level, but it does exist.
This is partly why most chip designers simply shrug off RISC v CISC comparisions
these days, since deep down most modern CPUs are virtually the same.
*/
outer RISC may be inferior to inner RISC + outer CISC,
/*
Regarding 32 registers on PPC, I wrote plenty of code that makes use of it.
You are incorrect about the implicit register backup required on the stack for
register based calls because the PPC open ABI defines those registers as volatile.
Just like you nevm
r need to worry about saving d0/d1/a0/a1 for most 680x0 stuff (and similarly
cannot assume they survive a function call), roughly half the registers of the
PPC ABI are volatile and can be used for argument passing and temporary local
variables.
*/
but say there are 16 such registers then they will not survive across function
calls,
if those 16 registers contain info needed beyond the calls then you have to
back them up to another 16 registers or the stack,
I think the function call convention is actually quite a difficult problem,
the best answer is probably somewhere in between what I am saying and what
you are saying, eg maybe:
1. small number of volatile scratch registers,
2. the first function arguments in non-scratch registers: if function arguments
are in scratch registers then those registers are no longer scratch!:
scratch registers are short term breathing space,
3. further arguments to the stack,
eg on 68k:
a0,a1,d0,d1 as scratch, and function arguments f(d2,a2,d3,a3)
if you have too many function arguments in registers you
run out of breathing space: the called function has to start using the
stack to free up registers for internal use,
also the calling function may already be using those registers for
something else so it has to back them up somewhere,
if you have too many scratch registers its wasteful,
So I concede that you need some register arguments but I differ with
68k AmigaOS in that I think they should be non scratch and not too many,
not too few either!
I also think you should have uniform register argument usage:
eg argument 1 is always d2,
in AmigaOS the usage is totally erratic eg: Open(d1,d2), FindTask(a1),
AllocSignal(d0), Enqueue(a0,a1)
I also differ in thinking that you only need 1 system variables register if any,
which would point to a structure containing the OS global variables,
/*
I wrote various matrix multiplication code for transforms on ppc (some of the
only hand asm I wrote) that is extremely fast since the entire transformation
matrix' terms remain in registers for any number of vertices processed. 12 floats
defining the buisness end of the matrix are held in volatile registers and you
even get single
cycle 4-operand multiply-add (register*register+register -> register) operations
to help when evaluating the matrix * vector stuff.
Literally, throught the loop the only stuff accessing memory was the instruction
stream, incoming vertices and outgoing transformed vertieces. And the loop, of
course pretty much stays in the cache
There is no way I could get say the 680x0 to get anywhere near the code efficiency
of it.
*/
I can believe that you generated optimal code relative to the PPC architecture,
if the CPU has lots of registers then you should make use of them if it makes
sense,
matrices would be very rapid with lots of registers,
to some extent optimal CPU design may depend on what you are using the
CPU for,
I think the design of an optimal FPU may be totally different from the
design of an optimal CPU,
FPU's are about real maths, whereas CPU's tend to be about
non maths stuff: addresses + flags + counts and such like,
flags are represented as numbers but they are not numbers but
booleans,
the maths involved in most of an OS is generally quite simple,
especially outside of graphics, most of an OS doesnt even require
floating point numbers,
the only use of floating points probably is for things like rendering
rescalable fonts,
/*
I know you don't see large register files as at all useful, but if you look at the
way present x86 processors actually work inside and the way they are going with
the 64-bit designs (IIRC, IA64 has 256 registers) I think you might be in a
minority.
*/
its survival of the fittest, just because some company or even all companies
makes some decision doesnt mean its correct,
most cars use petrol, but alcohol is sustainable and has no pollution:
alcohol turns into carbon dioxide and water, certainly no lead or fumes,
that carbon dioxide came from the atmosphere in the first place via
photosynthesis so its a clean cycle,
somewhere in South America they use alcohol powered cars,
and its quite viable: all you need is prairies filled with sugar cane
which you ferment, but there is probably 12 digit money politics
that makes sure we all use petrol,
I was talking about the fixed problem of what the PPC CPU does,
that a different architecture with the same technology could even be
4 x as fast,
FPUs are a totally different problem, eg vector processing in hardware
could make a huge difference:
have a very wide data bus and very wide vector registers,
then you can load a vector in one read cycle,
also 3D graphics is probably totally different from generic FPU use,
because in theory you could load an entire matrix in one read cycle,
in which case you only need 2 registers 1 for the matrix and one for
the vector,
if you have 32 bit 3 address instructions then you probably need
at least 16 opcodes == 4 bits which leaves 28 bits meaning that
512 registers is the maximum possible,
remember that vector maths is a very narrow slice of what computers are
used for thats why they dont use GPUs as CPUs!
I think we are starting to argue in circles,
-
@bloodline,
I spent several hours yesterday looking at Comet, Staples and PC World,
Comet have an entry-level system for £270 Intel based HP system,
but it uses a shared memory Intel graphics card,
£12.95 delivery charge,
128Meg ATI-Radeon 9xxx looks like its £100 at PC World,
Comet also do a £470 mid-level PC base unit also HP,
with 128 Meg ATI-Radeon 9xxx SE,
it has various things not in the £270 one eg writable DVD whereas
the £270 is read only for DVDs but writable for CDs,
all the systems in Staples seem expensive,
If I make a system from the parts via PCWorld its:
£52.86 for CPU, mobo £47.59, 128Meg RAM £22.33, 128 Meg ATI-Radeon £100,
case £35,
which adds up to £267.80 without s/w or OS,
unbundled MS OS is £160 I was told,
Fast SCSI-2 interface for external drives is 29.95 from PCWorld,
looking at real machines made me realise what an achievement it is
to get AROS to boot directly on PCs,
>>>>It would certainly be a great thing to have AROS running Nativly on the A1.
>>>The PPC Linux hosted version of AROS is coming on rather quickly thanks to Markus,
>>>who is resolving some stack issues, and attempting to get the Graphics drivers
>>>to work.
>for me the word Linux is underlined here,
>can this Linux work be reused in a directly A1 booting AROS?
/*
Yes, when you think of AROS Hosted, think of Linux as a Hardware abstraction layer.
Running AROS on Linux can be thought of as the same as running AOS3.1 in UAE.
While AROS is running on Linux one can work out all the bugs and issues.
Then you can add the Firmware boot code and boot AROS on it's own.
*/
ok thats good, it means indirectly they are working on a direct boot,
/*
It should be noteed at 99.9% of the AROS source code is cross platform,
it's just the CPU specific/ASM stuff that needs reworking.
*/
as it should be!
/*/*
I feel if I buy a PC I am a turncoat or traitor, however if AROS directly
boots ie no Windows and its not Intel then maybe thats better than
using IBM PPC on the A1?
Its strange that IBM are now "good" and Intel are "bad",
Having read the book "Big Blue" IMO IBM are anything but good,
and there is no basis for thinking Intel are "bad": Intel never
did anything "bad",
MS OTOH IMO are bad,
*/*/
/*
To be honest, the "good"/"bad" lables are a redundant conceptual model.
Nothing is good or bad, things fall into two categories, "Usefull" and "Useless"
with respect to your requirements.
Windows for example is "Useless" if I want to use an OS that looks and feels
the way I want an OS to look and feel, but it is "Useful" is I want to run a
certain peice of software.
*/
an interesting viewpoint,
certainly I dont like at all the Windows interface,
to me it says "go away", whereas the Amiga interface says "FUN-time"!
The bundles provide a full set of s/w, but I am really intent on
bypassing MS.
Its quite insiduous how they force themselves on you the customer,
the default line of action is you end up with Windows and all the MS s/w,
that would be ok if they manufactured the h/w but they dont,
so its not right,
looking at machines I dont get what the big deal is about MS,
they have created a drab looking OS and the only interesting thing about it
I can see is that all h/w is geared to run on it,
Really h/w manufacturers should be forced to release c drivers for their
products so any OS can use any driver,
it is truly sinful that 3rd party h/w can be produced to only run on Windows,
/*
When choosing hardware you must first consider what your requirements are,
then choose what is useful and at the cheapest price. Ignore religious/political
issues like "brand" and "make", these things are unimportant when it comes to
technology.
*/
I am upset though that something so horrible as MS has a stranglehold,
why cant we have a quality monopoly,
/*/*
How clean is PC AROS boot?
(the cleanness of the PPC AROS boot appeals to me),
Re PC AROS if I have understood you:
1. I buy a PC,
2. I download AROS,
3. I directly boot AROS?
4. I run UAE above AROS for full 68k compatibilty?
Is this correct?
*/*/
/*
Yes, just download the AROS CD image, burn that to a CD-ROM,
then put that in the CD drive, turn the PC on...
AROS will boot and run by itself.
*/
sounds painless, so in theory I dont need MS?
now could I do this via the PCs hard disk instead of via CD-ROM?
ie if I download to the hard disk could I boot from that instead?
or if I download to an external SCSI hard drive on the Amiga and
then connect this to the PC via the interface I mentioned,
or is it only possible via CD?
/*
You will presented with an early startup menu allowing you to select
certain hardware options (good news if you have a Nvidia gfx card),
or you can ignore them and it will boot after 5 seconds.
*/
looks like I will get an ATI Radeon if I get a PC or use the
onboard shared graphics Intel card,
/*/*
In the UK have you any tips about buying a new PC?
Are the places like PCWorld, Comet, Staples, Dixons a good place to try
or should I go to specialist shops eg from computer mag adverts?
*/*/
/*
I would build the machine myself. There are plenty of shorps that sell PC parts
for good prices. http://www.dabs.com is a great UK website selling top
quality parts for a low price.
Don't forget that Black Troll sell complete PC's with AROS already
installed for around £160 or so (depending upon the exchange rate).
High Street stores will rip you off.
*/
I will look into these then,
I read this after making yesterdays visit to those shops,
£160 is almost half the price of what I saw,
will the £160 PC come with MS OS or MS s/w or is MS completely absent?
what sort of graphics card?
do you think the shop bundles are there to catch ignorant first timers??
/*/*
>That's true, if we treated all memory access in AROS as Big Endien
>we could have the same 68k emulation method as OS4 and MorphOS use.
>But it has been decided that the performance penalty of running
>a little Endien CPU with Big Endian data was to significant
>(something like 30% penalty) that it was not worth it.
30% is nothing,
if a car goes by at 70mph and 10 minutes later another car goes by at 100mph
would you know the difference (I am talking about perceptions here),
(70mph being 30% slower than 100mph)
can you go both ways: ie have Big endian PC AROS and Little endian PC AROS,
*/*/
/*
30% is far too much. When running AROS on a 3.066Ghz CPU, are you
really happy to write off nearly a whole 1Ghz (919.8Mhz) of performance?
*/
it may depend on your upbringing, I was trained to never put speed as the
top priority, ie robustness + portability + compatibility etc are
higher up the ladder than speed
eg a formula 1 car is very fast but I dont see many people driving them
on the roads!
/*
There is no point to cripple a CPU, AROS runs using the Native byte order
of the CPU, thus it is big endien on 68k and PPC and little Endien on the x86.
*/
I dont mind though and many people are happy with WinUAE and Amithlon which
are big endian on x86,
the be686-amithlon-gcc shows that people are even prepared to produce
big endian compilers for x86,
/*
You could build a Big Endien AROS for the x86 but that would be incompatible
with the faster Little Endian one.
*/
effectively it would be AROS on a different platform,
it would be very interesting to see what exactly the slow down is,
you believe its 30% but as it hasnt been done we dont know for sure
/*/*
Besides if we use an integrated UAE we also get Hardware compatibility
>and improved stability so it's a benefit all round.
can you integrate UAE at the RAM level with little endian RAM?
if a 68k program accesses OS data structures ints and words at the byte level
or bytes at the word level the OS will get mangled
most programs wont do this so maybe you dont lose too much,
*/*/
/*
The Idea for the integrated UAE is so that the 68k and the x86 do not share
Data structures.
But instead allow the two system to synchronise their data.
*/
ok, you've gone down that path,
its going to be much more work,
I suppose if you redirect each 68k jump vector to also call the
corresponding x86 jump vector or something,
will each x86 API call have to synchronise the 68k data structures?
/*
This will allow 68k programs to run in the same environment as the x86 programs.
The only down side is that 68k programs will not be able to call x86
functions and vice versa. This could be possible, but probably not worth it.
The UAE Emulator will be running a 68k version of AROS (specially designed to
synchronise with the x86 version).
*/
I suppose the open nature of AROS means someone else could
create their own variant of AROS some other way, (I'm not volunteering just yet!)
whereas with AmigaOS we would all be stuck with the company's decision,
/*/*
everyone says its not a big deal that Eyetech created the A1,
I wondered whether they could prove this by doing their own one,
*/*/
/*
Anyone is able to sell Terrons.
I could put a little sticker on it if you like and sell it to you.
*/
see you are telling me its not a big deal,
how much would you sell it for?
/*/*
people on all Amiga variants could then start generating AROS native progs,
*/*/
/*
Since AROS is source code compatible with AmigaOS, it is easy to write your
program on your A1200 in C... and then take that source code to An AROS
machine and recompile for whatever CPU that is running.
gcc has a cross compiler, there is no probelm generating code for any
CPU from any CPU, providing you have the includes of course.
*/
your gcc outputs to multiple CPUs?
68k gcc only appears to output 68k series code,
but it sounds like your one outputs PPC and Intel code,
in which case there isnt an issue except for 68k people as it appears
you havent completed 68k Amiga AROS,
/*/*
computer 3D always sucks because you can literally see the computer slow down
and wince whenever something computationally complex happens,
*/*/
/*
I've guess you've not used a new 3D card then. I have yet to write a program
that causes my Radeon 9000 to slow down even with over 10000 objects
(using the DX7 interface).
*/
but as you throw more and more objects it must eventually slow down?
ie
for( i = 1 ; ; i++ ){ introduce_1000_objects() ; }
must eventually catch up with your CPU power,
how about 10000 explosions?
/*/*
Amiga.org is closed source isnt it?
*/*/
/*
No. Both Amiga.org and Amigaworld.net use xoops which is a great example of
opensource software. Aros-Exec.org also uses xoops.
*/
xoops is opensource but presumably the specific configuration is closed source??
/*/*
Note that if a 68k version is also done then it reaches all platforms via UAE,
so its just the native compile that would be lacking,
:this is a good reason for having a fully implemented 68k AROS,
*/*/
/*
We need the 68k AROS for the integrated UAE Emulator idea.
I also want to run AROS on my A1200. We do have a working 68k AROS,
but it needs to be adapted to boot the Amgia Hardwre.
At the moment it only boots the Palm PDA.
*/
reimplementing AmigaOS via the same custom chips!
you may need to study UAE to understand the custom chips!
(a bit like studying AROS to understand AmigaOS),
I hope you fix some of the existing bugs eg
AGA SetRGB32CM doesnt set the lower 4 bits of the blue component,
also blitter OS calls can fail horribly on bitmaps exceeding
1024 pixels width even though the h/w can cope with huge bitmaps,
according to the autodocs someone forget to set an AGNES big blit flag
they knew that in 1992 and havent yet fixed the bug!
/*/*
to this day I dont even know if closed source commercial binaries are
allowed on Linux,
*/*/
/*
It depends. If you link to a GPL library or use any GPL code,
then your software automatically becomes GPL.
If you link to an LGPL library then you program is not GPL or LGPL.
If you use any BSD code then that does does not cause your code to be BSD.
Simply check the licence of any software you are using to find out what you
can and can't do.
*/
so it can be done,
/*
AROS is covered by the APL, which is similar to LGPL. IF you use AROS source only
the code that you use must remain Opensource. The rest of your program is yours.
Licence issues are very complex.
*/
sounds a good license, some licenses are quite tight fisted!
-
Right, so you don't buy a mainstream PC, but then talk about buying parts from somewhere like Comet, Staples or PC-World. Thats like saving your foot then cutting your leg off. If you are going to build a machine, you use places like Komplett (http://www.komplett.co.uk), eBuyer (http://www.ebuyer.com), Scan (http://www.scan.co.uk) and Dabs (http://www.dabs.com). Also if you are going for more hardcore parts, possibly Overclock.co.uk and TekHeads. Going to high street crap places like Comet and PCW guarentee you nothing than high prices and a dire selection of parts that are nothing more than marketing gimmicks (i.e. GeForceFX 52XX cards etc).
Oh, you may want a hard-drive for that PC too :lol:
-
whoosh777 wrote:
@bloodline,
I spent several hours yesterday looking at Comet, Staples and PC World,
If it's your first PC it *might* be an idea to get a prebuilt system. But if you are going to do that, then still avoid the high streets. If you really must go the high street route, then use something like "Time Computers"... but if possible go to specialist dealer.
You say you want to avoid M$ Windows. I say that it makes sense to at least have a copy of 2000 or XP on your machine so you can run the lastest games, and/or any important apps you might need.
Always get as much RAM and Hard drive capacity as you can afford. Buying RAM and Hard drives from a specilist dealer (www.dabs.com are great) will always be at least 50% cheaper than the High street stores.
Fast SCSI-2 interface for external drives is 29.95 from PCWorld,
looking at real machines made me realise what an achievement it is
to get AROS to boot directly on PCs,
SCSI is pointless for any home user. Any modern drive (Like the Western Digital's with thier 8meg caches) will be much cheaper and offer similar performance. S-ATA is the new way to go so look for that if you can.
Don't forget that UAS2 and Firewire offer good Hard drive suppoer too, though both are pricey.
Yes, It is testiment to Michal Shultz, Johan Grip et al, hard work getting AROS booting the PC hardware. Though the fact that PCs have a standard BIOS does help.
/*
Yes, when you think of AROS Hosted, think of Linux as a Hardware abstraction layer.
Running AROS on Linux can be thought of as the same as running AOS3.1 in UAE.
While AROS is running on Linux one can work out all the bugs and issues.
Then you can add the Firmware boot code and boot AROS on it's own.
*/
ok thats good, it means indirectly they are working on a direct boot,
Bug fixes on any version of AROS directly improves all other versions. As I said AROS shares 99.999% of it's code across all ports.
/*
When choosing hardware you must first consider what your requirements are,
then choose what is useful and at the cheapest price. Ignore religious/political
issues like "brand" and "make", these things are unimportant when it comes to
technology.
*/
I am upset though that something so horrible as MS has a stranglehold,
why cant we have a quality monopoly,
M$ Windows simply offers a standard way for software to talk to both the user and the hardware. It does that job very well. I it a shame hadware manufactures often only provide Windows drivers, and never any source code. but Since windows *is* the standard this is little we can do about it, unless we offer a viable alternative for the user.
/*
Yes, just download the AROS CD image, burn that to a CD-ROM,
then put that in the CD drive, turn the PC on...
AROS will boot and run by itself.
*/
sounds painless, so in theory I dont need MS?
now could I do this via the PCs hard disk instead of via CD-ROM?
ie if I download to the hard disk could I boot from that instead?
or if I download to an external SCSI hard drive on the Amiga and
then connect this to the PC via the interface I mentioned,
or is it only possible via CD?
Wndows provides internet access and CD burning software, that alone makes it useful.
To run AROS it needs to be either on a CD or on a floppy. From the CD you can install it onto a hard drive and once there it can boot without a Flopyp or CD
AROS needs to be running in order to install itself on to a hard drive.
To put the AROS boot image onto a Floppy you will need a high density drive. To put the AROS boot iamge on a CD you will need a CD burner.
I recommend you get a CD burner with your PC.
/*
I would build the machine myself. There are plenty of shorps that sell PC parts
for good prices. http://www.dabs.com is a great UK website selling top
quality parts for a low price.
Don't forget that Black Troll sell complete PC's with AROS already
installed for around £160 or so (depending upon the exchange rate).
High Street stores will rip you off.
*/
I will look into these then,
I read this after making yesterdays visit to those shops,
£160 is almost half the price of what I saw,
will the £160 PC come with MS OS or MS s/w or is MS completely absent?
what sort of graphics card?
do you think the shop bundles are there to catch ignorant first timers??
The Black Troll machine is an AROS system, it does not come with Windows. It might not be ideal for your needs.
The shop bundles do catch the first timers, but then they do make things very painless for the first timer too.
/*
30% is far too much. When running AROS on a 3.066Ghz CPU, are you
really happy to write off nearly a whole 1Ghz (919.8Mhz) of performance?
*/
it may depend on your upbringing, I was trained to never put speed as the
top priority, ie robustness + portability + compatibility etc are
higher up the ladder than speed
eg a formula 1 car is very fast but I dont see many people driving them
on the roads!
But a 3Ghz PC is not the F1 of the PC world, it's the standard. Anyway I think a computer runing at 2/3s it's actaull speed is not a good trade off so you can run an old Application that is probably far behind in features than a freeware Windows version.
when you could go the integrated UAE route and run that same app on a system running at full speed.
The Compatibility desire is what held the PC and Windows back. That is why I used to hate them. Amiga Users should not become stuck in that mind set also.
/*
You could build a Big Endien AROS for the x86 but that would be incompatible
with the faster Little Endian one.
*/
effectively it would be AROS on a different platform,
it would be very interesting to see what exactly the slow down is,
you believe its 30% but as it hasnt been done we dont know for sure
It would be a different AROS platform, in the same way the PPC verison of AROS is.
Tests have confirmed that the slow down would be significant.
Amithlon has the advantage that even the lowest spec PC taking a 30% speed hit is still 10 times faster than the fastest real Amiga. As Amithlon runs software meant for a real Amiga it's no great loss.
But how would you feel if you wrote a program and compiled it for Linux, Windows and AROS. And the AROS version was 30% slower than the Windows and Linux versions on the same machine? that sux, no one would bother with the AROS version because it is crippled. No speed penalty is worth it.
Also if the 68k was "inline" then the AROS would be less stable, as bugs in old programs would be allowed to creep in and take down the OS. If we run them in UAE, when they die, you can simily restart them. The OS remains uncrashed.
/*
The Idea for the integrated UAE is so that the 68k and the x86 do not share
Data structures.
But instead allow the two system to synchronise their data.
*/
ok, you've gone down that path,
its going to be much more work,
I suppose if you redirect each 68k jump vector to also call the
corresponding x86 jump vector or something,
will each x86 API call have to synchronise the 68k data structures?
It would be up to the 68k verison working with UAE to make sure it knows what the x86 OS is doing.
If you call a function in a library on the 68k side that function will then call the coresponding function on the x86 side performaing any byte order conversions if needed.
/*
This will allow 68k programs to run in the same environment as the x86 programs.
The only down side is that 68k programs will not be able to call x86
functions and vice versa. This could be possible, but probably not worth it.
The UAE Emulator will be running a 68k version of AROS (specially designed to
synchronise with the x86 version).
*/
I suppose the open nature of AROS means someone else could
create their own variant of AROS some other way, (I'm not volunteering just yet!)
whereas with AmigaOS we would all be stuck with the company's decision,
You could, if you want, right now get the AROS sources and add in your own "inline" 68k emulator and make a big endian verison of the x86 AROS. The devs would even help you as best they can. That is the beauty of Open source software.
/*/*
everyone says its not a big deal that Eyetech created the A1,
I wondered whether they could prove this by doing their own one,
*/*/
/*
Anyone is able to sell Terrons.
I could put a little sticker on it if you like and sell it to you.
*/
see you are telling me its not a big deal,
how much would you sell it for?
It was a brave market decision to push a PPC platform at that price, but I guess Eyetech knew people would buy anything with an Amgia Sticker on it.
Sure I'll sell you one, hmmm how does $14 billion sound?
/*/*
computer 3D always sucks because you can literally see the computer slow down
and wince whenever something computationally complex happens,
*/*/
/*
I've guess you've not used a new 3D card then. I have yet to write a program
that causes my Radeon 9000 to slow down even with over 10000 objects
(using the DX7 interface).
*/
but as you throw more and more objects it must eventually slow down?
ie
for( i = 1 ; ; i++ ){ introduce_1000_objects() ; }
must eventually catch up with your CPU power,
how about 10000 explosions?
A Modern graphics card has a GPU (a dedicated Processor) that is as powerfull as super computers were 10 years ago. When programming 3D with a modern Graphics Card (using DirectX or OpenGL, whatever) you left the GPU do all the hard stuff and left the CPU worry about the game logic.
You will have to see the performance to believe it.
/*
No. Both Amiga.org and Amigaworld.net use xoops which is a great example of
opensource software. Aros-Exec.org also uses xoops.
*/
xoops is opensource but presumably the specific configuration is closed source??
the configuraton has nothing to do with the source.
/*
We need the 68k AROS for the integrated UAE Emulator idea.
I also want to run AROS on my A1200. We do have a working 68k AROS,
but it needs to be adapted to boot the Amgia Hardwre.
At the moment it only boots the Palm PDA.
*/
reimplementing AmigaOS via the same custom chips!
you may need to study UAE to understand the custom chips!
(a bit like studying AROS to understand AmigaOS),
I hope you fix some of the existing bugs eg
AGA SetRGB32CM doesnt set the lower 4 bits of the blue component,
also blitter OS calls can fail horribly on bitmaps exceeding
1024 pixels width even though the h/w can cope with huge bitmaps,
according to the autodocs someone forget to set an AGNES big blit flag
they knew that in 1992 and havent yet fixed the bug!
Booting UAE would be much easier than a Rael Amiga, since one could bypass the hardware bootstrap. Using UAE one might be able to figure out how the hardware is initilised at power on.
In the 68k version of AROS, one would not have the same bugs as AmigaOS, unless there is specific reason to copy that bug.
/*
AROS is covered by the APL, which is similar to LGPL. IF you use AROS source only
the code that you use must remain Opensource. The rest of your program is yours.
Licence issues are very complex.
*/
sounds a good license, some licenses are quite tight fisted!
A licence is there to allow the user to use the softwre while at the same time protecting the author of the software.
If it fails to do either of these things, the Licence is bad.
-
Time Computers have not existed for a while, they merged with Tiny and I do NOT recommend their machines.
-
Fast SCSI-2 interface for external drives is 29.95 from PCWorld,
SCSI-2 is 20MB/s. Current IDE drives are roughly 50-60MB/s. Why exactly do you want SCSI-2?
-
NightShade737 wrote:
Time Computers have not existed for a while, they merged with Tiny and I do NOT recommend their machines.
REally? But Tiny machines were crap.
in 2000 I knew 5 people who bought computers. Two went to Time, 3 went to Tiny... One tiny machine was DOA, One of the Tiny machine died after a year and a bit... and the other Tiny machine died after about 2 years.
The time machines are still going... that's why I figured they are ok.
But I personally build my own machines, you get better quality components at a cheaper price. Dabs are great! :-)
-
Komplett are better :) (used all of the companies multiple times). Dabs are good. West Mercia police use them for most their stuff as I did some ordering and such for them, but Kompett excell in the RMA department, their prices are also a bit lower.
Yeah, the hardware was rugged. I still have parts from 1998 Time machines that are fine, what isn't fine is their support, extras and setup, but as I said, they haven't existed for a while anyway.
-
bloodline wrote:
NightShade737 wrote:
Time Computers have not existed for a while, they merged with Tiny and I do NOT recommend their machines.
REally? But Tiny machines were crap.
in 2000 I knew 5 people who bought computers. Two went to Time, 3 went to Tiny... One tiny machine was DOA, One of the Tiny machine died after a year and a bit... and the other Tiny machine died after about 2 years.
The time machines are still going... that's why I figured they are ok.
But I personally build my own machines, you get better quality components at a cheaper price. Dabs are great! :-)
Tiny went bankrupt over 2 years ago. Time's parent company bought the trading name Tiny from the recievers and launched another company Tiny.com that is separate from Time. Time are retail only, Tiny.com are web/phone mail order only.
There is nothing wrong with the hardware either sell, jsut the sh!te software installed on them. Cheifly Windows. All the users are thick as fcuk too, 99% of problems on support calls are problems caused by the user. You need a licence to drive a car, IMHO you need one to use windows.
-
@whoosh777
Heh, we're not arguing, just comparing chip implementations. I still say, considering your enthusiasm for the idea, go for it! :-D
Anyhow, back to that circle :-D
1. small number of volatile scratch registers,
2. the first function arguments in non-scratch registers: if function arguments
are in scratch registers then those registers are no longer scratch!:
scratch registers are short term breathing space,
3. further arguments to the stack,
eg on 68k:
a0,a1,d0,d1 as scratch, and function arguments f(d2,a2,d3,a3)
if you have too many function arguments in registers you
run out of breathing space: the called function has to start using the stack to free up registers for internal use,
also the calling function may already be using those registers for something else so it has to back them up somewhere,
if you have too many scratch registers its wasteful,
I sincerely suggest you read the PPC open ABI specification to get a better understanding of how it works. The issues you raise almost never occur due to how the ABI is layed out. Stack based calling is rare (unless you have more than 8 integer/pointer parameters). Those registers never need to be backed up before a call because the compiler won't use them to hold anything that needs to survive a call.
As you yourself point out, 4 registers is usually enough for most purposes. With 32 registers, some of which are used for the stack, global data section etc, the compiler can almost always find somewhere to store a variable without using the stack.
Even then, the compiler can spot which volatile registers don't get hammered across calls in the same translation unit. Same with function parameters, it can see which ones 'survive' the call, eg const arguments etc.
When I look at well optimised PPC code generated from a good compiler, I see very little stack usage, very little register backup etc.
Now, if you think back to your "stack cache" idea, having a large register file, of which programming standards say "this half is volatile etc." actually gives you the same functionality.
Large register files are fantastically useful for breaking down complex expressions. All the examples you have posted so far tend to deal with linear code, doing fairly simple arithmetic.
x = a + b * (c + (d*d)); etc.
Chuck in function calls (some of which may be inlined), multidimensional pointer dereferences (that may be used several times in one expression), etc., and more and more volatile registers becomes useful to hold temporaries that may be needed more than once.
For a different example of why large register sets are handy, a small interpretive emulator I wrote as a thought experiment (for a theoretical bytecode cpu), uses several function lookup tables. One for opcodes, one for effective address calculation and one for debugging traps etc.
There is a data structure for the "core", containing a register file, stack (seperate ones for data, register backup and function call) and code pointer (the PC, but expressed as absolute address) etc.
Code is executed in blocks, until either a certian number of statements have been executed, or a particular trap (or break signal) has been invoked.
Careful design of the code allowed each function table base, the virtual register file, the virtual stack pointers and code pointer to persist in the same registers throught a call to execute(), without the need to be moved, saved etc. etc. across all the calls incurred during execution of the bytecode. Given that we are talking about possibly millions of calls, that saving is considerable.
Regarding the x86 internal RISC issue, I never said that it was better or worse than "up front" RISC.
But we can infer 2 things:
1) A RISC style core clearly makes sense as virtually every CPU manufacturer is using it.
2) Your assumption that the "external CISC" style approach of x86 could be better based on code density is very difficult to judge. You have to consider that the code decomposition into the internal micro op language is far from simple to achieve. The design of these cores are fantastically complicated, gobbling up silicon like nobody's buisness.
The problem is, it's not a simple linear process where x86 instruction "X" is always decomposed into micro-op codes "a b c". The early stage of decode may work this way but once it has to start processing "a b c", it almost works like a mini compiler, looking to see what rename registers are/will become free, which instructions have dependencies etc. All this takes clock cycles - which is partially why modern x86 CPU's have such very long pipelines and "time of flight" for instructions.
The above work is largely non existant for up-front RISC designs because it's a compile time issue. They still have to worry about rename registers and such, but compile time instruction scheduling has made their life a lot easier.
In fact, part of the whole point of RISC is that it makes the CPU's life easier by making the compilers life more difficult :-D
Now, the present x86 designs uses the above internal RISC approach not because they thought "Hmm, this is better than those young whipper snapper RISC cpu's", but because they *had* to keep x86 object code compatibility and newer RISC style processors emerging were seriously threatening them.
You only have to look back at the time when x86 introduced these RISC style cores and DEC still made the Alpha AXP. We had several Windows NT workstations in our spectroscopy labs at Uni, one was using the latter at 266 MHz and we had a newer P-II 300 MHz, with it's new spanking "internal RISC style core" and the alpha still stuffed it :-D
-
Yeah, the hardware was rugged. I still have parts from 1998 Time machines that are fine, what isn't fine is their support, extras and setup, but as I said, they haven't existed for a while anyway.
WTF????? They are the biggest and oldest PC manufacturer in the UK.
What do you base your opinion on that support is not good? Personal experience?
-
Yeah, parents wanted a pre-built machine to start with, and I got sick of dealing with their customer support as they basically had no idea what they were talking about. Can't remember any specifics anymore as it was 6 years ago, but I remember they weren't good.
-
NightShade737 wrote:
Yeah, parents wanted a pre-built machine to start with, and I got sick of dealing with their customer support as they basically had no idea what they were talking about. Can't remember any specifics anymore as it was 6 years ago, but I remember they weren't good.
Things change. :-)
-
@bloodline,
I decided to buy a cheapest possible high street pre-built system,
mainly to get Windows + a full set of s/w, even though I am trying
to bypass Windows:
it seems I can literally pull out and replace anything in this
eg motherboard or CPU and turn it into a totally different system,
having it pre-built will help me see how its put together, and supplies
me with OS + lots of s/w which would cost a bomb to buy directly,
anyway it has DVD ROM, CD writer, 256 Mb RAM, shared memory gfx card,
floppy drive, keyboard, mouse, lots of sockets eg USB, Ethernet,
I connected it up and installed the system,
now seemed the right time to visit the aros sites, so I visited
www.aros.org, (I think thats the URL),
First I tried your floppy image,
www.aminet.net progs for creating floppies from disk-images are
geared to 880K disks, so I quickly wrote a prog,
found I needed to use mfm.device to access PC1:, I copied the image,
AmigaOS now not recognizing the disk and it failed to boot the PC,
it left the disk running permanently, perhaps there is a bug,
anyway I gave up, I have attached the
prog at the end of this post in case you can see a bug,
Now I downloaded the CD image in about 1 hour, much faster than
via my A1200, (I have unlimited internet but not broadband),
FIRST PROBLEM:
my PC refuses to understand .tar.bz2,
I try the WindowsXP help search facility, tar and untar do *not* exist,
I try google, "MSDOS" and "tar", one link says:
"tar is a unix thing, if you have a tar archive its not for the PC!"
another link is "IT experts", they know about tar for PC, but I have
to subscribe for $9/month to know the answer,
I know how to use tar, but I want the binary,
eventually I give up, basically its currently impossible to extract your
compressed ISO image, all the Gigabytes of Windows XP are to no avail `cos
their search engine says so, XP understands music and videos but not your
compressed CD,
no probs for my A1200,
anyway I burned with no probs the renamed compressed ISO to CD-R on the PC,
then loaded this onto my A1200,
OS3.9 Unarc took too long on decompressing .bz2 so I halted it and tried
Geek:
bunzip2 -fkvL AROS_CD.tar.bz2
45? minutes to decompress to AROS_CD.tar,
Geeks tar was taking too long so I tried Unarc again,
Unarc did it within an hour,
BTW the tar compression is utterly pointless:
AROS_CD.tar.bz2: 17Meg,
AROS_CD.tar and AROS_CD are both about 52 meg, a tiny insignificant
compression,
I would tell you the exact number but Fryingpan (see later) fried my
partition containing the AROS CD binaries, so its deactivated temporarily
via early startup,
The only way to transfer this decompression is via a CD-R:
Next problem, I dont have any CD burning s/w for my A1200,
I tried the free version of MakeCD but every 20 seconds it comes up
with some kind of write error,
So I downloaded Fryingpan from www.aminet.net, the interface takes 10 years
to render, the docs are in png files, and I cannot get it to burn the CD-R,
it understands my drive, but no luck,
Net effect is I cannot install AROS,
If you can make available the full uncompressed CD I can then generate
it via the PC's s/w,
alternatively supply a link to tar and full instructions on how to
decompress this, because Geek things are forbidden territory to my
Windows XP system, probably because they are a Unix thing,
I noticed you have the 17 Meg doubly compressed CD and another 18Meg one,
so probably you have enough webspace to have the full uncompressed CD,
I think it will take 3 hours to download it, but then decompressing
the compressed one takes some 2 hours, so its space-time vs decompression-time,
please remove the .tar compression because it adds an extra hour and
achieves 0.000000000001 % compression improvement IYSWIM,
Anyway net effect is I dont have AROS installed:
my PC cannot decompress it, my Amiga can but I cannot transmit it between the
2 computers except by sending a 52Meg binmail on my A1200 which will
probably take 20 hours to transmit and ?? hours to upload into YAM,
my website is only 30Meg so its not big enough for me to upload it via the A1200
and download it via the PC,
unless you can point me to a free CD burner that will run on my SCSI system,
BTW the reason I want a SCSI interface is for my existing SCSI drives:
2 hard disks and my CDRW,
I looked also into WinUAE and found their webpage totally confusing,
and soon gave up. I have a real Amiga but didnt see any info on how to
capture the ROM, though I didnt look too thoroughly,
-
@NightShade737
/*
Right, so you don't buy a mainstream PC, but then talk about buying parts from
somewhere like Comet, Staples or PC-World. Thats like saving your foot then
cutting your leg off.
*/
I decided in the end that a cheapest possible high street machine is worth
it just for the official s/w, from then onwards I think I will not use those places,
as this is my first PC I decided the convenience was worth it,
BTW I transported it by taxi which was £4 cheaper than the shops transport charge,
PC-World charges £200 for ATI-Radeon 9800, but I saw somewhere on the
internet selling it for £150,
there seem to be many ATI-Radeon versions eg 7xxx, 9600, 9800,
which versions are good and A1 + Pegasos compatible and which arent?
(the earlier versions can be quite cheap, but are they useless?),
PC-World has an Invidia 128Meg (I think) Ge-force or something for £99,
/*
If you are going to build a machine, you use places like Komplett, eBuyer, Scan
and Dabs. Also if you are going for more hardcore parts,
possibly Overclock.co.uk and TekHeads. Going to high street crap places like
Comet and PCW guarentee you nothing than high prices and a dire selection
of parts that are nothing more than marketing gimicks
(i.e. GeForceFX 52XX cards etc).
*/
For further h/w I will look into these links,
can you give a list of graphics cards worth looking into?
where will I get a cheapest possible ATI-Radeon 9800?
£150 is the cheapest I have found, (inc VAT I think),
also where can I get a VGA switcher: ie to switch between my A1200 and PC,
the ones I saw in PC-World are some £80 to £100 which seems a bit expensive
for some wires and a switch, I dont care if it says Belkin or NASA on it,
/*
Oh, you may want a hard-drive for that PC too
*/
they supply a 40Gig one, Windows seems to be pre-installed on it:
no Windows CD,
there is a DVD with 6 Windows progs,
-
You really need to be a LOT more specific. You can't just say Radeon 9800, or even worse just GeForce. The name GeForce has been given to a line of cards spanning ~5 years, so giving me a price and saying GeForce doesn't mean anything.
The price on the 9800 is also useless unless it has an extension (SE, Pro, XT). From that price I guess it is an SE, which is a BAD price (roughly £115 new anywhere else). It could be a plain one with no extension, but you need to specify. The PC-World site gives me 2 hits, neight for that price.
VGA switches can range from £10 to £200, the price depends on the output quality and the features. Pay more if you want better quality.
I have no idea on A1 or Peg compatability as I don't care about either.
-
I forgot to attach the binary-image to MSDOS disk program,
is this program correct?
#include /* just includes */
#include
#include
#include
#include
int main( int argc , char **argv )
{
int ret = 20 , closer = 0 , SECTOR_SIZE , SECTOR_NUM , sector ;
struct MsgPort *TrackMP = 0 ;
struct IOExtTD *TrackIO = 0 ;
UBYTE *WriteBuffer = 0 ;
struct DriveGeometry *geom = 0 ;
FILE *fp = 0 ;
if( argc < 3 )
{
printf("%s binary_file unit [for_real]\n" , argv[0]) ;
printf("eg\n%s ram:xys 1 1\n for PC1:" , argv[0] ) ;
return( 20 ) ;
}
fp = fopen( argv[ 1 ] , "r" ) ;
if( fp==0 ){ printf("couldnt open %s\n" , argv[ 1 ] ) ; return( 20 ) ; }
TrackMP = CreatePort( 0 , 0 ) ;
if( TrackMP==0 ){ printf("CreatePort error\n" ) ; goto cleanup ; }
TrackIO = (struct IOExtTD *)CreateExtIO( TrackMP , sizeof( struct IOExtTD ) ) ;
if( TrackIO==0 ){ printf("CreateExtIO error\n"); goto cleanup ; }
if( OpenDevice( "mfm.device" , atoi( argv[ 2 ] ) , (struct IORequest *)TrackIO , 0 ) )
{
printf("failed to open drive %d\n" , atoi(argv[2]));
closer = 0 ;
goto cleanup ;
}
else closer = 1 ;
geom = AllocVec( sizeof( struct DriveGeometry ) , MEMF_PUBLIC | MEMF_CLEAR ) ;
TrackIO->iotd_Req.io_Data = geom ;
TrackIO->iotd_Req.io_Command = TD_GETGEOMETRY ;
DoIO( (struct IORequest *)TrackIO ) ;
printf("sector size=%d, numsectors = %d\n" , geom->dg_SectorSize ,
geom->dg_TotalSectors ) ;
SECTOR_SIZE = geom->dg_SectorSize ;
SECTOR_NUM = geom->dg_TotalSectors ;
printf("sectors/track = %d, numsectors = %d\n" , geom->dg_SectorSize ,
geom->dg_TotalSectors ) ;
if( argc==3 )goto cleanup ;
/* bytes/sector, sectors/drive, cylinders, sectors/cylinder, surfaces,
sectors/track,
*/
/* only support: full-sector writes on sector boundaries */
WriteBuffer = AllocVec( SECTOR_SIZE , MEMF_CLEAR | MEMF_PUBLIC ) ;
for( sector = 0 ; sector < SECTOR_NUM ; sector++ )
{
PutStr(".") ; Flush( Output() ) ;
fread( WriteBuffer , 1 , SECTOR_SIZE , fp ) ;
TrackIO->iotd_Req.io_Length = SECTOR_SIZE ;
TrackIO->iotd_Req.io_Data = WriteBuffer ;
TrackIO->iotd_Req.io_Offset = SECTOR_SIZE * sector ;
TrackIO->iotd_Req.io_Command = CMD_WRITE ;
DoIO( (struct IORequest *)TrackIO ) ;
}
ret = 0 ;
cleanup:
if( WriteBuffer ){ FreeVec( WriteBuffer ) ; WriteBuffer = 0 ; }
if( geom ){ FreeVec( geom ) ; geom = 0 ; }
if( closer ){ CloseDevice( (struct IORequest *)TrackIO ) ; }
if( TrackIO ){ DeleteExtIO( (struct IORequest *)TrackIO ) ; TrackIO = 0 ; }
if( TrackMP ){ DeletePort( TrackMP ) ; TrackMP = 0 ; }
if( fp ){ fclose( fp ) ; fp = 0 ; }
return( ret ) ;
}
-
@bloodline,
re: big vs little endian PC AROS,
perhaps a practical path is 2 versions thus:
1. Uncompromising little endian, *no* backward 68k compatibility,
aimed as the long term version of AROS,
2. Big endian shared OS data structures version for full 68k compatibility,
as a short term version of AROS in order to attract 68k owners,
A lot of people will not use AROS unless it has full 68k compatibility,
I know this because I mentioned about AROS booting on PCs to someone I know
who has his finger on the pulse of the scene and he underlined the fact
that AROS has limited 68k compatibility. When this guy raises an objection,
you have to listen, anyway I heard him,
usually we criticise people for being too short termist,
but here for the first time is an approach that maybe is too long termist,
The advantage of 2. is all it requires is a 68k emulator,
and a chipset emulator implemented via the AROS API,
ie no ROM,
simply subdivide RAM into 3: 1. x86 code area, 2. 68k code area, 3. other,
when x86 is active execute protect 2.,
when emulator is active read protect 1.,
the paging exceptions toggle between x86 and emulator,
this requires your OS datastructures to be at the byte level identical to
68k,
so its simply a matter of carefully slotting in a 68k emulator, and
also implementing the custom chipset via the AROS API,
/**
I spent several hours yesterday looking at Comet, Staples and PC World,
**/
/*
If it's your first PC it *might* be an idea to get a prebuilt system.
*/
worth it for the Windows stuff, the way they bundle Windows is a bit
like a drug pusher giving you some free drugs to begin with,
/*
But if you are going to do that, then still avoid the high streets.
If you really must go the high street route, then use something like
"Time Computers"... but if possible go to special)
st dealer.
*/
I visited Time, but they seemed a bit expensive and their systems
include eg monitor, possibly they are good value if you also need a monitor,
BTW I looked at the ATI-Radeon demo of a butterfly flying up to a chimpanzee,
when the salesman showed me that you could go to any viewpoint in the sequence
I realised what you meant,
things have moved on a lot since I last looked,
/*
You say you want to avoid M$ Windows. I say that it makes sense to at least have a
copy of 2000 or XP on your machine so you can run the lastest games,
and/or any important apps you might need.
*/
its a way out of compatibility problems, also it has been very revealing to
see just what MS are up to, more on this later,
/*
SCSI is pointless for any home user. Any modern drive
(Like the Western Digital's with thier 8meg caches) will be much cheaper and
offer similar performance. S-ATA is the new way to go so look for that if you can.
Don't forget that UAS2 and Firewire offer good Hard drive suppoer too,
though both are pricey.
*/
SCSI is just for my existing drives: I have 2 SCSI hard disks and 1 CDRW,
I like external drives because I can switch them off if I go on the internet
to prevent viruses,
I want to try and run my system entirely from external drives that way
internet drives will never be on at the same time as my programming drives,
to prevent viruses, I will switch off the one lot and switch on the internet
drive before connecting,
/*
Yes, It is testiment to Michal Shultz, Johan Grip et al,
hard work getting AROS booting the PC hardware.
Though the fact that PCs have a standard BIOS does help.
*/
backwards compatibility is their Achilles heel for alternative OS's?
for me so far this PC looks totally impenetrable,
I am getting a very clear picture now about what Windows really is,
and I think AmigaOS has a lot to offer,
At the moment I am alternating between the 2 systems by reconnecting just
my VGA socket and modem socket, so I can really know the truth now about
AGA A1200 vs current PC,
no more FUD possible because I now have both real things, real Amiga h/w and
real PC h/w
and its a current Windows XP machine,
/*
/*
/*
When choosing hardware you must first consider what your requirements are,
then choose what is useful and at the cheapest price. Ignore religious/political
issues like "brand" and "make", these things are unimportant when it comes to
technology.
*/
*/
*/
/*
/*
I am upset though that something so horrible as MS has a stranglehold,
why cant we have a quality monopoly,
*/
*/
/*
M$ Windows simply offers a standard way for software to talk to both
the user and the hardware. It does that job very well.
I it a shame hadware manufactures often only provide Windows drivers,
and never any source code. but Since windows *is* the standard)
this is little we can do about it, unless we offer a viable alternative for the user.
*/
the guy in PC World agreed that I could use Linux, but they dont bundle Linux,
/*
/*
Yes, just download the AROS CD image, burn that to a CD-ROM,
*/
*/
correction:
``Yes, just download the AROS CD doubly compressed image,
decompress it if you can *to* a PC, burn that to a CD-ROM,''
famous last words!
/*
then put that in the CD drive, turn the PC on...
AROS will boot and run by itself.
*/
not reached this stage yet,
/*
Wndows provides internet access and CD burning software, that alone makes it useful.
*/
I decided it was worth getting Windows, one should know what the competition is
up to, having tried out their system I dont think its a big deal,
IMO you could implement Windows XP in a few megabytes,
I've not seen the API but certainly the functionality is just
a few megs worth,
the OS3.9 CD provided quite comparable music + video viewing programs,
in fact I keep getting deja-vu trying out Windows XP,
when I begun the install I thought "this is OS1.2 MS AmigaBasic",
the install couldnt cope with the fact that I hadnt got any loudspeakers,
the text scrolling is really horrible,
King-Con's AGA shell history scrolling p*sses all over WindowsXP,
I wonder if maybe Windows XP was written in Microsoft's AmigaBasic??
every now and then I get a glimpse of the pre-Windows MSDOS black screen
with pulsating cusor, so they must have recycled some really ancient and
decrepit code,
My AGA Prefs totally outdo what this PC provides, this PC presents me
with about 3 screen resolutions all of which are wrong,
with AGA its near infinite, I believe also that AGA outdoes graphics cards
in such respects,
IMO AGA "high res" ie 640 x 256 screen is perfect, somehow if the res is
too high and there are too many colours I find I cannot focus on the
information.
despite all the graphics power if I change the screen resolution I can
literally see the subrectangles been drawn, slower than my AGA system,
its sufficiently slow that I think I may even be able to figure out what
rendering algorithm they are using, it looks really silly,
this machine is allegedly > 100 x as powerful as my A1200,
something doesnt add up,
please do not ever compare graphics card classic Amigas with AGA Amigas,
apart from the interleaved bitmaps AGA is actually quite fantastic,
Somehow if the interface is too "beautiful" then I cannot
focus my thoughts, so eg I much prefer fixed width fonts: because they
are bland I can focus on what is being said,
in the same way ugly politicians are preferable because
you can focus on the policies and not be distracted by
any charm element,
I wont get any programming done if I used some publishing quality
variable width fonts,
likewise if they sung the news it would be very difficult to focus on
the meaning,
the music player is fantastic sound quality, the sharpness (on my headphones)
felt like my eardrums were being etched, the Mozart was well chosen and well
performed (or is it Beethoven?), but one of the other 2 options has the
most humdrum lyrics ever, something on the level of
"I pared my toenails, then I stood up and looked at the light bulb",
at one point he sings about "breathing in", I will see if I can transcribe
the lyrics and maybe post them somewhere,
/*
To run AROS it needs to be either on a CD or on a floppy.
From the CD you can install it onto a hard drive and once there it can
boot without a Flopyp or CD
*/
I had no luck with the floppy, but there may be a bug in the program I wrote,
rather than debug it I thought I would try the CD path,
I think you need to supply or link to enough PC s/w to do the install,
the floppy binary doesnt seem worth compressing: compressed its 1.2 meg,
decompressed 1.4 meg (I think),
If you can bug fix my program maybe compile it and supply it for people
to install the floppy binary,
/*
AROS needs to be running in order to install itself on to a hard drive.
*/
ok, so its a 2 stage "bootstrap" install,
/*
The Black Troll machine is an AROS system, it does not come with Windows. It might
not be ideal for your needs.
The shop bundles do catch the first timers, but then they do make things very
painless for the first timer too.
*/
I think its only after you buy the machine that it dawns on you that
its not actually a computer but lots of units connected together,
and any of these units can be transplanted for low cost,
PC World told me I could buy a motherboard for a mere £47.59,
less than the CPU: £52.88,
so for less than £100 I can transplant these 2 items and have a totally
different machine,
eat your heart out Dr Frankenstein!
/***
You could build a Big Endien AROS for the x86 but that would be incompatible
with the faster Little Endian one.
***/
/**
effectively it would be AROS on a different platform,
it would be very interesting to see what exactly the slow down is,
you believe its 30% but as it hasnt been done we dont know for sure
**/
/*
It would be a different AROS platform, in the same way the PPC verison of AROS is.
Tests have confirmed that the slow down would be significant.
Amithlon has the advantage that even the lowest spec PC taking a
30% speed hit is still 10 times faster than the fastest real Amiga.
As Amithlon runs software meant for a real Amiga it's no great loss.
*/
/*
But how would you feel if you wrote a program and compiled it for Linux,
Windows and AROS. And the AROS version was 30% slower than the Windows and
Linux versions on the same machine? that sux, no one would bother with the
AROS version because it is crippl)
d. No speed penalty is worth it.
*/
very few people would measure it, the speed critical routines could
always be rewritten in little endian,
the idea of speed being a secondary issue is very much a Unix concept,
its certainly where I learnt the concept from, our department was
Unix through and through,
Unix programs are really bloated and inefficient,
the reason Unix is so widespread and successful is they put portability
and maintainability etc above speed decades ago,
c is also a Unix thing, the idea being that if you write an OS in c,
to port your OS all you have to do is port the c compiler,
we all take this for granted now but that was a radical innovation,
the fact that even AROS hinges on gcc proves this, and gcc is
many times more inefficient than Lattice C,
gcc is slow + totally portable,
Lattice C is very fast and produces faster binaries,
but AROS is using the slow compiler which produces the slow binaries,
all because someone put speed as a secondary issue,
we were taught that what really matters is asymptotic speed,
bubble sort is no good because it is an n-squared algorithm,
good algorithms are n-log-n,
dont worry about constant linear factors we were told again and again,
in lecture after lecture, dont worry even if the linear factor is 300%
Quicksort is said to be probably the fastest sorting algorithm on typical input
with average speed of n-log-n, however in the worst case it is n-squared,
so I wont use it, but a lot of people will and its in the standard c library
as qsort(),
:I will never use it because I believe in
robust algorithms == best worst case behaviour,
if you know a system is using a non robust algorithm
you could bring it to its knees by sending it the worst case situation,
some sorting algorithms grind to a halt or stack-overflow if you send
an already sorted list or a reverse sorted list,
viruses are all about worst case scenarios,
if a star-wars defence system algorithm has bad asymptotic behaviour
all the enemy has to do to defeat it is send a huge number of missiles
ie overload it with computational complexity,
send 2 batches of missiles, the first without warheads the second with,
:who knows it may even cause stack overflow!,
(computers are capable of quite awesome clangers),
or if for speed they are using a 16 bit register for number of incoming
missiles then send the missiles in batches of say 65536,
and it will think its 0 missiles causing 65536 missiles to get through,
(to play it safe exceed 65536 by some "safety" margin),
we were told that the US military likes networks where if you
blow up any node the full message still gets through intact!
they put this above speed, if you put speed topmost then
you could remove error detection and precompute
the path that a message would take which could be much faster,
but instead a message is broken up into pieces and the route is
recomputed afresh each time, the pieces could arrive in the wrong order,
so the receiver has to rearrange them into correct sequence => extra
space + time overhead,
/*
Also if the 68k was "inline" then the AROS would be less stable,
as bugs in old programs would be allowed to creep in and take down the OS.
If we run them in UAE, when they die, you can simily restart them.
The OS remains uncrashed.
*/
UAE will have its own WB screen or UAE + AROS will share the same WB screen?
/**
will each x86 API call have to synchronise the 68k data structures?
**/
/*
It would be up to the 68k verison working with UAE to make sure it
knows what the x86 OS is doing.
If you call a function in a library on the 68k side that function
will then call the coresponding function on the x86 side performaing
any byte order conversions if needed.
*/
probably it is doable in the sense that it may just require a few
minutes to patch each API call,
/***
This will allow 68k programs to run in the same environment as the x86 programs.
The only down side is that 68k programs will not be able to call x86
functions and vice versa. This could be possible, but probably not worth it.
The UAE Emulator will be running a 68k version of AROS (specially designed to
synchronise with the x86 version).
***/
/**
I suppose the open nature of AROS means someone else could
create their own variant of AROS some other way, (I'm not volunteering just yet!)
whereas with AmigaOS we would all be stuck with the company's decision,
**/
/*
You could, if you want, right now get the AROS sources and add in your own
"inline" 68k emulator and make a big endian verison of the x86 AROS.
The devs would even help you as best they can. That is the beauty of
Open source software.
*/
I may study some possibilities, I think at the moment its going to be
a challenge just to get "hello world" up and running on this PC,
this option for anyone at all to take AROS in their own direction
is a robustness feature of the AROS project,
eg with Amiga co. I feel they should have used Intel (or clone) and not PPC,
also I think they should have emulated OS3, released that and then begun on
new work OS4,
had it been AROS, Berndt would have gone down that path some years ago,
Eyetech being a h/w manufacturer strategically cannot go down
the Intel path because they would factor themselves out of the equation!
/****
everyone says its not a big deal that Eyetech created the A1,
I wondered whether they could prove this by doing their own one,
****/
/***
Anyone is able to sell Terrons.
I could put a little sticker on it if you like and sell it to you.
***/
/**
see you are telling me its not a big deal,
how much would you sell it for?
**/
/*
It was a brave market decision to push a PPC platform at that price,
but I guess Eyetech knew people would buy anything with an Amgia Sticker on it.
Sure I'll sell you one, hmmm how does $14 billion sound?
*/
how much profit do you think they make then per board?
is it just a matter of taking a standard PC and replacing the mobo by a Terron?
/**
but as you throw more and more objects it must eventually slow down?
ie
for( i = 1 ; ; i++ ){ introduce_1000_objects() ; }
must eventually catch up with your CPU power,
how about 10000 explosions?
**/
/*
A Modern graphics card has a GPU (a dedicated Processor) that is as powerfull as super computers were 10 years ago. When programming 3D with a modern Graphics Card (using DirectX or OpenGL, whatever) you left the GPU do all the hard stuff and left the CPU )
orry about the game logic.
You will have to see the performance to believe it.
*/
I saw the chimp + butterfly demo in TIME yesterday, so I think I understand now
what you meant,
each leaf in that jungle would take an A500 ages to render,
it made me think of ground-hog-day, the butterfly appears to repeatedly fly
along exactly the same path,
I remember when people would leave their A500 running through the night
to render a teapot + billiard ball and things, (not every night!),
/***
We need the 68k AROS for the integrated UAE Emulator idea.
I also want to run AROS on my A1200. We do have a working 68k AROS,
but it needs to be adapted to boot the Amgia Hardwre.
At the moment it only boots the Palm PDA.
***/
/**
reimplementing AmigaOS via the same custom chips!
you may need to study UAE to understand the custom chips!
(a bit like studying AROS to understand AmigaOS),
I hope you fix some of the existing bugs eg
AGA SetRGB32CM doesnt set the lower 4 bits of the blue component,
also blitter OS calls can fail horribly on bitmaps exceeding
1024 pixels width even though the h/w can cope with huge bitmaps,
according to the autodocs someone forget to set an AGNES big blit flag
they knew that in 1992 and havent yet fixed the bug!
**/
/*
Booting UAE would be much easier than a Rael Amiga, since one could bypass the
hardware bootstrap. Using UAE one might be able to figure out how the hardware
is initilised at power on.
*/
I think the early initialisation is documented at the back of some of the RKMs,
have a look in both the first and second edition RKMs,
Alternatively have a read of some of the assembler-games-writing tutorials
in the Amiga mags of long ago, the cover disks supplied assembler complete with
explanations,
/*
In the 68k version of AROS, one would not have the same bugs as AmigaOS,
unless there is specific reason to copy that bug.
*/
the graphics render bugs need fixing,
I think printer.device retains bugs for compatibility:
ISTR the autodocs discuss these bugs,
-
@whoosh777
Re: .tar.bz2 files.
If I recall correctly, TAR is not intended to compress the contents, it's a simple archiving format. The reason this is done is because you can only bzip individual files. It's a "Unix thing" indeed, but you can open then on Windows if you have WinRAR (http://www.rarlabs.com/download.htm).
It's fully-functional shareware, not difficult to find. Try not to freak out too much.
-
IMO you could implement Windows XP in a few megabytes,
I've not seen the API but certainly the functionality is just a few megs worth,
:lol: Tell it to Microsoft :-D
The truth is
1) There's a vast amount of redundancy in windows. There are literally dozens of different was a user can do the same thing.
2) There's tons of functionality most people aren't aware of and wouldn't neccessarily use even if they were. Loads of services and other features are included that the average home user has no idea about.
3) When updating windows resources, it's extremely rare to find that a set of .dll files or whatever are actually updated as it's not time/cost effective for MS to bother. Most of the time, newer .dll files are simply added. There's a lot of historic bloat alone that comes from this.
4) Most likely your preinstalled windows xp has system restore and other features enabled. This is basically like having a copy of the CD in a folder under your xp installlation and if something goes wrong, you can restore the last working configuration.
In the end, it all adds up to one gargantuan behemoth :-D
-
Edit: the source code has been improved via some but not all of
Pirus suggestions from a reply to this posting in the future!
:the program is also improved now to read + write any binaries
eg AmigaOS and PC,
The PC MSDOS disk binary writer is correct provided you create a binary
by the same method, just tested it out and it correctly copied a PC disk,
you can download the 68020 binary + source here:
http://www.whoosh777.pwp.blueyonder.co.uk/trackdisk.lha
[code]
/************** Usage: ***************/
run with no arguments or just 1 argument ? for usage info
convert disks to and from binary files, usage:
prog binary_file unit (w|r) (device)
w => write to disk read from file,
r=> read from disk write to file
default device==mfm.device for PC disks
trackdisk.device for AmigaOS disks,
use other devices at your own risk: BEWARE
examples:
trackdisk ram:xyz 0 r trackdisk.device ; create AmigaOS df0: binary ram:xyz
trackdisk ram:xyz 2 w trackdisk.device ; write to AmigaOS df2: from binary ram:xyz
trackdisk ram:uvw 1 r ; create PC1: binary ram:uvw
trackdisk ram:uvw 1 r mfm.device ; create PC1: binary ram:uvw
trackdisk ram:uvw 1 w mfm.device ; write to PC1: from binary ram:uvw
trackdisk ram:uvw 1 w ; write to PC1: from binary ram:uvw
/*************************************/
the improved source with complete headers is:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
extern struct ExecBase *SysBase ;
int main( int argc , char **argv )
{
struct Task *task = FindTask( 0 ) ;
int ret = 20 , read = 1 , write = 0 ,
closer = 0 , SECTOR_SIZE , SECTOR_NUM , sector ;
unsigned SIGNAL = SIGBREAKF_CTRL_E ;
struct MsgPort *TrackMP = 0 ;
struct IOExtTD *TrackIO = 0 ;
UBYTE *WriteBuffer = 0 ;
struct DriveGeometry *geom = 0 ;
FILE *fp = 0 ; BPTR out = Output() ; char *device = "mfm.device" ;
if( argc < 3 )
{
FPrintf( out , "convert disks to and from binary files, usage:\n" ) ;
FPrintf( out , "\nprog binary_file unit (w|r) (device)\n\n" ) ;
FPrintf( out , "w => write to disk read from file,\n"
"r=> read from disk write to file\n"
"default device==mfm.device for PC disks\n"
"trackdisk.device for AmigaOS disks,\n"
"use other devices at your own risk: BEWARE\n"
"\n\nexamples: \n\n"
"%s ram:xyz 0 r trackdisk.device ; create AmigaOS df0: binary ram:xyz\n"
"%s ram:xyz 2 w trackdisk.device ; write to AmigaOS df2: from binary ram:xyz\n"
"%s ram:uvw 1 r ; create PC1: binary ram:uvw\n"
"%s ram:uvw 1 r mfm.device ; create PC1: binary ram:uvw\n"
"%s ram:uvw 1 w mfm.device ; write to PC1: from binary ram:uvw\n"
"%s ram:uvw 1 w ; write to PC1: from binary ram:uvw\n" ,
argv[ 0 ] , argv[ 0 ] , argv[ 0 ] ,
argv[ 0 ] , argv[ 0 ] , argv[ 0 ]
) ;
return( 20 ) ;
}
if( argc==3 || tolower(argv[ 3][0])=='w' )
{ read = 0 ; write = 1 ; fp = fopen( argv[ 1 ] , "r" ) ; }
else { read = 1 ; write = 0 ; fp = fopen( argv[ 1 ] , "w" ) ; }
if( argc >= 5 )device=argv[ 4 ] ;
if( fp==0 ){ FPrintf( out , "couldnt open %s\n" , argv[ 1 ] ) ; return( 20 ) ; }
TrackMP = CreatePort( 0 , 0 ) ;
if( TrackMP==0 ){ FPrintf( out , "CreatePort error\n"); goto cleanup ; }
TrackIO = (struct IOExtTD *)CreateExtIO( TrackMP , sizeof( struct IOExtTD ) ) ;
if( TrackIO==0 ){ FPrintf( out , "CreateExtIO error\n" ) ; goto cleanup ; }
if( OpenDevice( device , atoi( argv[ 2 ] ) , (struct IORequest *)TrackIO , 0 ) )
{
FPrintf( out , "failed to open drive\n" );
goto cleanup ;
}
closer = 1 ;
geom = AllocVec( sizeof( struct DriveGeometry ) , MEMF_PUBLIC | MEMF_CLEAR ) ;
if( geom==0 ){ FPrintf( out , "failed memory allocation\n"); goto cleanup ; }
TrackIO->iotd_Req.io_Data = geom ;
TrackIO->iotd_Req.io_Command = TD_GETGEOMETRY ;
if( DoIO( (struct IORequest *)TrackIO ) )
{ FPrintf( out , "i/o error, quitting\n" ) ; goto cleanup ; }
FPrintf( out , "sector size=%ld, numsectors = %ld\n" , geom->dg_SectorSize ,
geom->dg_TotalSectors ) ;
SECTOR_SIZE = geom->dg_SectorSize ;
SECTOR_NUM = geom->dg_TotalSectors ;
FPrintf( out , "sectors/track = %ld, sectors/cylinder = %ld\n" ,
geom->dg_TrackSectors , geom->dg_CylSectors ) ;
if( argc==3 ){ ret = 0 ; goto cleanup ; }
/* bytes/sector, sectors/drive, cylinders, sectors/cylinder, surfaces,
sectors/track,
*/
/* only support: full-sector writes on sector boundaries */
WriteBuffer = AllocVec( SECTOR_SIZE , MEMF_CLEAR | MEMF_PUBLIC ) ;
if( WriteBuffer==0 ){FPrintf( out , "memory allocation failed\n" ); goto cleanup ;}
PutStr( "type control-E to quit\n" ) ;
for( sector = 0 ; sector < SECTOR_NUM ; sector++ )
{
int amount ;
if( task->tc_SigRecvd & SIGNAL )
{
Wait( SIGNAL ) ; /* no wait, to clear the signal */
PutStr("\n***Break\n" ) ; Flush( out ) ;
goto cleanup ;
}
PutStr(".") ; Flush( out ) ;
amount = SECTOR_SIZE ;
if( write )
{
amount = fread( WriteBuffer , 1 , SECTOR_SIZE , fp ) ;
if( amount < SECTOR_SIZE )
{ ret = 20 ; FPrintf( out , "file ends early\n"); }
if( amount==0 )break ;
TrackIO->iotd_Req.io_Command = CMD_WRITE ;
}
else TrackIO->iotd_Req.io_Command = CMD_READ ;
TrackIO->iotd_Req.io_Length = SECTOR_SIZE ;
TrackIO->iotd_Req.io_Data = WriteBuffer ;
TrackIO->iotd_Req.io_Offset = SECTOR_SIZE * sector ;
{
int err , count ;
count = 0 ;
while( 1 )
{
if( task->tc_SigRecvd & SIGNAL )
{
Wait( SIGNAL ) ; /* no wait, to clear the signal */
PutStr("\n***Break\n" ) ; Flush( out ) ;
goto cleanup ;
}
err = DoIO( (struct IORequest *)TrackIO ) ;
if( err==0 )break ;
if( err )FPrintf( out , "DoIO error %ld\n" , err ) ;
count++ ;
if(count==5){FPrintf( out , "I give up,\n" ) ; goto cleanup;}
}
}
if( read )
{
amount = fwrite( WriteBuffer , 1 , SECTOR_SIZE , fp ) ;
if( amount < SECTOR_SIZE )
{ FPrintf( out , "file error\n"); goto cleanup ; }
}
if( amount < SECTOR_SIZE )break ;
}
ret = 0 ;
cleanup:
if( WriteBuffer ){ FreeVec( WriteBuffer ) ; WriteBuffer = 0 ; }
if( geom ){ FreeVec( geom ) ; geom = 0 ; }
if( closer ){ CloseDevice( (struct IORequest *)TrackIO ) ; }
if( TrackIO ){ DeleteExtIO( (struct IORequest *)TrackIO ) ; TrackIO = 0 ; }
if( TrackMP ){ DeletePort( TrackMP ) ; TrackMP = 0 ; }
if( fp ){ fclose( fp ) ; fp = 0 ; }
return( ret ) ;
}
[\code]
-
#include <pragmas/exec_pragmas.h>
#ifdef LATTICE
#include <clib/exec_protos.h>
#endif
#include <clib/alib_protos.h>
#include <clib/exec_protos.h>
#include <clib/dos_protos.h>
Use:
#include
#include
#include
instead. More portable.
int ret = 20;
Use:
int ret = RETURN_FAIL;
later, ret = RETURN_OK; and ret = RETURN_FAIL;
TrackMP = CreatePort( 0 , 0 ) ;
if( TrackMP==0 ){ printf("CreatePort error\n"); goto cleanup ; }
TrackIO = (struct IOExtTD *)CreateExtIO( TrackMP , sizeof( struct IOExtTD ) ) ;
Use CreateMsgPort/DeleteMsgPort and CreateIORequest/DeleteIORequest. Why use amiga.lib when these routines are in exec.library ?
WriteBuffer = AllocVec( SECTOR_SIZE , MEMF_CLEAR | MEMF_PUBLIC ) ;
geom = AllocVec( sizeof( struct DriveGeometry ) , MEMF_PUBLIC | MEMF_CLEAR ) ;
Allocation can fail. You MUST check for NULL result from AllocVec and act accordingly.
mixing printf and PutStr / Flush
Don't mix stdio and dos.library calls. This won't work properly (output problems due to buffering). Either use only stdio functions or only dos.library functions.
In fact, there is no need to use stdio in the program, just use dos.library and get rid of all stdio stuff. The code will never be portable anyway, so why use stdio?
DoIO( (struct IORequest *)TrackIO ) ;
IO can fail. You should implement retry (maybe 5 times), and if retry fail, report the error.
-
@Karlos
BTW you are in good company with your views, as they are
exactly what we were taught by our computing lecturers,
eg RISC better than CISC, many registers = good idea,
I went away believing that, but several years later
I bought a PC mag and it said that Intel CISC are the
fastest consumer CPUs,
and from my education I had thought "by now RISC such as
in MIPS will have totally superceded Intel",
so at that point I begun to doubt the conventional wisdom,
and then here in the Amiga forums we were told again and again
that Intel totally outdoes PPC RISC, PPC RISC is very similar to
MIPS RISC, this further underlined my loss-of-faith in
the conventional view,
As its off topic, if you wish to continue the discussion
perhaps we should continue via email but possibly not on a
daily basis as time is currently in very short supply!
/*
I sincerely suggest you read the PPC open ABI specification to get a
better understanding of how it works.
*/
where would I find this?, any URL?
/*
The issues you raise almost never occur due to how the ABI is layed out.
Stack based calling is rare (unless you have more than 8 integer/pointer part
meters). Those registers never need to be backed up before a call because the
compiler won't use them to hold anything that needs to survive a call.
*/
if you have a huge number of registers, then subject to that
you could have eg 100 scratch registers, 100 function argument registers,
100 internal function registers etc,
my question is whether you could achieve identical results with say just 16
registers via careful register usage, I think you can and that
a lot of chip complexity clutter can be swept out, resulting in a much
faster chip,
BTW one area where register arguments is a bit awkward is with
variable argument functions such as printf() and AmigaOS taglist functions,
accessing the n-th argument becomes longer, because your initial 8 registers
will need extra code, the only way out is if the h/w allows you to treat
the registers as an array,
another subtlety is that in c I can do:
int f( int x ){ int *y = &x ; ... }
ie I can take the address of a function argument, its not a big deal but
it means you would have to copy x to a stack cell that now represents x,
here is a taglist fragment from a real program of mine, 26 arguments,
and this is quite typical of intuition.library taglist calls:
screen = OpenScreenTags
(
NULL ,
SA_Interleaved , interleaved ,
SA_DetailPen , detailpen ,
SA_BlockPen , blockpen ,
SA_Behind , TRUE ,
SA_Depth , depth ,
SA_Width , width ,
SA_Height , height ,
SA_Title , (int)title ,
SA_ShowTitle , TRUE ,
SA_AutoScroll , autoscroll ,
SA_Overscan , OSCAN_TEXT ,
SA_DisplayID ,screenmode ,
TAG_DONE
) ;
generally taglists are heavyweight API calls so the time factor is
irrelevant,
/*
When I look at well optimised PPC code generated from a good compiler,
I see very little stack usage, very little register backup etc.
*/
count also the register usage, ie how many different registers get used,
IMO this will often be much smaller than you imagine,
(depends how good the compiler is),
BTW IMO optimisation is a relic from the days when computers had
1kb of memory and were 10 instructions/second,
todays computers are so ridiculously fast that optimisation
is no longer the issue it once was,
I once wrote a simple file splitting program, ie
prog file 1000
will split file into 2 files file1 and file2 where file1 is 1000 bytes
and file is the conctenation of the 2,
I did it via a fputc( fgetc(in_fp) , out_fp ) ; loop,
it was very slow, so instead I replaced it with a
amount = fread( array , 1 , 30000 , in_fp ) ;
fread( array , 1 , amount , in_fp ) ;
loop, this caused a staggering speedup,
Now had I compiler-optimised the original program, it would have
made no difference,
ie the slowness was caused by a factor on a higher plane, way beyond
the scope of a compiler,
Often program speed is determined by what type of h/w i/o caching is used
(as above), or what memory-allocation mechanism is used,
:compiler optimising such programs (eg gcc -O2 -c prog.c -o prog.o)
will not speed it up, the slowness being on a higher plane,
this is why our lecturers were entirely right in telling us to always
focus on the algorithms and not on system-specifics such as computer language,
with disk i/o you can use your eyes and ears, if the prog makes the disk leds
light up smoothly with silence then the algorithm is good, but if the
led's blink rapidly and the drive makes a noise its a bad algorithm,
/*
All the examples you have posted so far tend to deal with linear code,
doing fairly simple arithmetic.
x = a + b * (c + (d*d)); etc.
*/
most of an OS is like this,
take the c: directory, most of the maths is quite trivial,
if you type:
c:list ram: lformat="%p%n" all
the program recursively calls Examine(), it will have the directory name
in a string and then concatenate each filename to this string,
which it then prints,
so the maths really is totally trivial, mainly + to determine stringlength,
its quite a bit of effort to write:
lots of trawling through the dos.library autodocs, my datesorter prog
involves this sort of code,
anyway most of an OS is conceptual rather than mathematical,
eg the concept of a Task doesnt involve maths, a task is a non
mathematical thing, the maths would be eg seeing if another task
has a high enough priority to pre-empt it,
eg if a waiting task is awoken by say control-C in its window,
the OS will see if its priority is sufficiently high to
immediately pre-empt the executing task,
Wait( SIGBREAKF_CTRL_C ) ;
/*
Chuck in function calls (some of which may be inlined),
multidimensional pointer dereferences (that may be used several times
in one expression), etc., and more and more volatile registers
becomes useful to hold temporaries that may be needed more than once
*/
vector maths I think may require totally different CPU architecture,
Oh BTW one thing I thought of is that probably the speed of 3D games
maybe is decided by the speed of the graphics card,
so maybe PPC 3D games and Intel 3D games will run at identical speeds?
maybe even A1200 + ATI-Radeon 9800 will be very impressive??
Graphics cards seem now to be the most expensive part of PCs,
£199 for ATI-Radeon, £80 for VGA switcher box, £53 for CPU,
£48 for mother-board, in PC World,
:puts things in perspective,
-
Re: 68k AGA AROS + UAE => winner!
by Karlos on 2004/4/17 17:07:17
Quote:
/**
IMO you could implement Windows XP in a few megabytes,
I've not seen the API but certainly the functionality is just a few megs worth,
**/
/*
Tell it to Microsoft
The truth is
1) There's a vast amount of redundancy in windows.
There are literally dozens of different was a user can do the same thing.
*/
too many help options, which also makes it difficult to remember which help option led to some useful help,
/*
2) There's tons of functionality most people aren't aware of and wouldn't
neccessarily use even if they were. Loads of services and other features are
included that the average home user has no idea about.
*/
its an exercise in intimidation and dumbing down,
If you brought in a bulldozer and removed all the progs then
I think the few megs I mentioned would remain,
AmigActive magazine was quite capable of filling an entire CD with
huge amounts of interesting material, thats where I got my free MakeCD
from for example.
:I think any of their coverCD's would give Windows XP a good run for its money!
Windows also have taken much too much trouble in prettifying the interface,
I am much more interested in ease of use and what a prog does than
in the appearance,
/*
3) When updating windows resources,
*/
I havent got that far yet!
/*
it's extremely rare to find that a set
of .dll files or whatever are actually updated as it's not time/cost
effective for MS to bother. Most of the time, newer .dll files are simply added.
There's a lot of historicC
bloat alone that comes from this.
*/
probably I will understand this later,
it seems everything is going to be .xyz
.dll .exe
/*
4) Most likely your preinstalled windows xp has system restore and other
features enabled. This is basically like having a copy of the
CD in a folder under your xp installlation and if something goes wrong,
you can restore the last working configuration.
In the end, it all adds up to one gargantuan behemoth
*/
annoying that they didnt give me an XP CD,
all the years of MS FUD are very rapidly caking off!
active mice pointers really irritate me, on my A1200 the mouse is totally passive
as you move it along nothing happens till you actively click,
(except those equally irritating help bubbles on some Amiga progs,
with MakeCD I had real difficulty rotating the options because the
help bubble was in the way and I couldnt get around it to the
rotator-thingy it described),
Its going to be really good fun finding out the truth about this system,
-
@that_punk_guy
Re: .tar.bz2 files.
/*
If I recall correctly, TAR is not intended to compress the contents,
it's a simple archiving format. The reason this is done is because you can only
bzip individual files.
*/
I wasnt aware of this, I never paid too much attention to the sizes before,
I only noticed it this time because of the hugeness,
on the Amiga the word "archive" has tended to be used synonymously with
the word "compressed",
/*
It's a "Unix thing" indeed,
*/
actually to be pedantic is it more of a Linux thing?
I say this because I had to port bzip2 myself to the Amiga as it wasnt
on Geekgadgets, I needed it for rpm which is Red hat,
it was the easiest port ever, I think it took 15 minutes to port on my
68030 A1200, a straight recompile,
rpm OTOH is a nightmare port (to classic 68k Amiga, for Linux it will
of course be a mere recompile),
my port of bzip2 is on the rpm.html page of my website,
and its there as a .tar.gz file (for reasons of self-referentiality!)
isnt gzip the Unix thing??
/*
but you can open then on Windows if you have WinRAR.
*/
thanks for the link, this may fix the problem,
/*
It's fully-functional shareware, not difficult to find.
*/
but I am a PC newbie!
/*
Try not to freak out too much.
*/
sorry!
I am really freaked out about DiskSalv though, using it to fix the
damage done by Fryingpan.lha: DiskSalv wiped out the bin directory
of my GeekGadgets,
I only discovered this when I attempted to use something in gg:bin/
luckily I dont trust DiskSalv and copied the entire partition to
another partition before attempting it,
:this backing up of the unwritable partition with 600 Meg of files took
many many hours,
So I will have to copy all the wiped out stuff back via script,
I think I will never use DiskSalv again, how dare it and FryingPan
wipe out Geek, I wonder what other damage was done, the script I will use
will tell me,
luckily I also have 2 backups of all work directories, though a few weeks of work
is not backed up except backed up to another partition,
I remember the OS3.9 install overwrote everything on the partition,
-
@NightShade737
/*
You really need to be a LOT more specific.
You can't just say Radeon 9800, or even worse just GeForce.
The name GeForce has been given to a line of cards spanning ~5 years,
so giving me a price and saying GeForce doesn't mean anything.
*/
I have absolutely no idea, I just bought the PC, so I know zilch about this, its all jibberish to me!
the machine currently has a shared memory Intel extreme graphics card, a cousin of the machine has 9800 SE,
can you name specifics that I should look for?
/*
The price on the 9800 is also useless unless it has an extension (SE, Pro, XT).
From that price I guess it is an SE, which is a BAD price
*/
/*
(roughly £115 new anywhere else).
*/
which site has it at this price, how does the SE compare with the others,
eg whats missing or is it slower??
will the Chimp + butterfly demo run on all 3?
/*
It could be a plain one with no extension,
but you need to specify. The PC-World sit
gives me 2 hits, neight for that price.
*/
the PC World one is £199,
/*
VGA switches can range from £10 to £200,
the price depends on the output quality and the features.
Pay more if you want better quality.
*/
I want cheapest simplest possible, where should I look for a £10 one?
all I want is to connect my PC and A1200 to the same VGA TFT,
so I dont need one which can deal with 8 monitors or does keyboards as well,
merely 2 computer VGA cables in and one monitor VGA cable out,
at the moment I reconnect the VGA cable while all 3 machines are switched off,
/*
I have no idea on A1 or Peg compatability as I don't care about either.
*/
fine,
I forgot to ask: AROS compatibility also matters, or will they all function
on AROS?
-
@bloodline,
YAH:-D:-D:-D:-D!!!!!!!!!!
I've done it!
the earlier link to WinRAR did the trick,
so thanks to the guy who pointed that out,
though it was some effort due to the impenetrable
Wind:pissed:ws XP interface, you have to go through a maze whenever you want to switch activity,
First attempt didnt b:griping:t as it was the .tar archive!
So one further decompression via WinRAR and then
burnt :madashell: yet another CD-R (luckily I bought 10),
This time it b:lol::lol:ted!
I had to witness some ancient MSD:crazy:S screens and
then:
a Workbench with
2 icons: Ram: looking like a microchip and the CD's icon,
15.5 Meg graphics ram in the title and 236.7Meg other! :-D
:first time on this new PC that I've seen how much
ram I have!
Up till this point I had only been thinking of AROS as
source code, but here it was entirely a real interface,
It is an Amiga, it has its own flavour but it is
recognisably an Amiga,
and its a truecolour workbench because there is a
colour circle demo program showing a continuum of
colours,
its certainly a reimplementation,
it even has Prefs programmes,
I forget if it was in Prefs but I saw Zune#?
but didnt think of trying it out,
I set my keyboard repeat + delay without probs
via one of the Prefs programs,
I also changed it to a US keyboard as the
positioning of the non-alpha-numeric characters
is better thought out,
I eventually found the shell, via c:Newshell,
I changed the long shell prompt to > via c:prompt,
A lot has been done and a lot of libraries are present,
:kitty: kitty looks real in truecolour)
enough is certainly up and running to make it
worth writing programs for,
the fact that I saw a Ram: icon says that
intuition + graphics + dos + exec are done!
which for me is almost everything,
other than the #?.device's, I didnt check
which of these are done,
its going to take some time to get used to
the fact that I can now actually look at the
source code, its like a huge gate has been opened
and we can all walk in and press the buttons on
the control panels of the OS!
:I am so entrenched in the 3rd-party-developer mindset,
vs the OS-contributor mindset,
until now the OS was entirely in the hands of an elite,
who decided on our behalf,
I can already see one program I can create
by recycling existing code,
the required library being present there,
I couldnt find gcc, so I presume its on
www.aros.org, (or is it www.aros.com?),
I think the things which are missing are
what makes the project interesting from a
programmer POV,
so its almost like you can reinvent the wheel :roflmao:
your own way,
double clicking a text file makes it automatically view,
so I double clicked s:startup-sequence,
its very cheeky because it is a real startup-sequence,
serving the real purpose but its not the official one,
Before you can write programs for AROS you will have to
check whether the required libraries are present,
anyway a lot of existing programs should port very
rapidly as the central stuff is present,
its lucky that I follow the minimalist principle when
coding, ie use the absolute minimum of external dependencies eg I strictly program within OS3.0
and cybergraphics.library,
I presume you have reimplemented cyber??
(I will find out soon enough!),
I noticed arosc.library (I think), so I presume that is
standard c things as a shared library??
this is also my first visit to amiga.org in truecolour
via internet explorer, its a totally different website
via this browser + XP,
Ibrowse is ahead in that there is an editor button
so I can edit in Memacs, also on IBrowse I can
reply to a post via "view in new browser" : where
the reply happens in an Ibrowse folder!,
so eg on Ibrowse you can open all the pages of a
thread as lots of folders, which is really useful!
:not as lots of windows but folders like in YAM,
You can tell that this is a developer driven system
in stark contrast to the kid-gloves approach of
Wind:pissed:ws XP by the fact that
it has a program PCI Tool which shows you in great
detail all sorts of PCI stuff that I dont understand,
they'd never let you see things like
that on Wind:admonish:ws XP,
I got the feeling somehow of an engineering workshop,
that people are actively making the system take shape,
I could almost smell the engine oil,
So I've just seen the little-endian Intel-AROS,
until this point that phrase was just a concept for me,
and in a way it is an OS4 on Intel and you arent
afraid to let people try it out,
will it be possible to see my PC's hard disk on screen?
It will be very revealing to look in it via Amiga:roll:S,
Anyway trying something out is so different from talking about it,
I finished the session by trying out the Amiga's
3 key reset and yes the machine reset, though
XP didnt reboot,
The close down procedure of :ak47: XP :destroy: has a reset button so
it must be possible,
-
2) Your assumption that the "external CISC" style approach of x86 could be better based on code density is very difficult to judge. You have to consider that the code decomposition into the internal micro op language is far from simple to achieve. The design of these cores are fantastically complicated, gobbling up silicon like nobody's buisness.
One problem, PowerPC 970 has ~52 million transistors i.e. such transistor count is similar to the Athlon XP(Barton core).
In estimating the transistor count for AMD’s K8 core one can do the following;
1. Athlon FX’s ~90 million transistors minus Athlon 64 ~77 million transistors. This gives us an estimated single channel memory controller count i.e. ~13 million.
2. Athlon 64 ~77 million minus 13 million gives 64 million transistors. Athlon 64 with AGP tunneling/hyper transport interface and 1MB L2 cache consumes about 64 million transistors.
As one can see, K8 core and K7 Barton core is in range of PowerPC 970's transistor count.
All this takes clock cycles - which is partially why modern x86 CPU's have such very long pipelines and "time of flight" for instructions.
Note that PowerPC 970 has a comparable pipeline depth as with Athlon XP(Barton core). Try comparing it with an AMD solution instead of Intel's solution.
We had several Windows NT workstations in our spectroscopy labs at Uni, one was using the latter at 266 MHz and we had a newer P-II 300 MHz, with it's new spanking "internal RISC style core" and the alpha still stuffed it
Note that Alpha sports an EV6 bus advantage, why try it with EV6 bus enabled K7 Athlons?
-
@Hammer
It totally depends on what your transisters are used for :-D
How much of the modern x86 die is given up to x86 -> micro op decode, how much is given up to crutchhing up the "classic" x86 support?
How much of hte 970 transistor count is needed for legacy support? Virtually nothing.
Incidentally, I'm not the one who started the PPC v Intel debate here ;-)
Anyway, my point here is that the core of modern x86 processors is comparable to modern day RISC, hence the old "CISC v RISC" arguments are largely irrelavent in modern designs. Your PPC v AMD comparison makes that even more evident.
Note that Alpha sports an EV6 bus advantage, why try it with EV6 bus enabled K7 Athlons?
Dude, this was around start 1997. I should have made that clear - it's been a while since I was at Uni, you see. There were no Athlons and I'm not sure what sort of bus the Alpha was using then. But, it completely stuffed the new P2 systems that came to "replace it", which was rather amusing.
@whoosh777
I agree, the fastest consumer processors are x86 currently. That doesn't mean they are achitectually superior - as I say, they use many RISC paragdims in their cores to acheive the performance they reach. There is absolutely *no way* a conventional "classic x86" core, soley depending upon the 486 register set could get this far. The chip designers realised this a decade ago when the first "many register load/store" processors were crucifying them performance wise :-D
However, the x86 was already massively popular. They are the most competitively developed processors because the market is so ripe. Now it is dominated by Intel and AMD. A decade ago, there were many rivals.
Anyway, the point is, the "large register count / RISC is better view" has been largely proven. As I said, internally, x86 manufacturers moved their cores this way quite some time ago. What would have been truly interesting is to see what their cores would be like if they were packaged as a pure RISC processor, without all the x86 decode. For example, the P2 core has something like 64 (or maybe 128, I don't remeber) registers used for rename and shadowing.
-
@bloodline,
it occurred to me that for tricky and undocumented PC h/w,
it may be an idea to borrow freely from the Bochs ("think in the box!")
project,
I cannot find the archive for the URL, but use google, I downloaded and
decompressed it ages ago, though did nothing further with it as I was
too busy with other projects,
below is a recursive list of all subdirectories of Bochs,
right now I am trying to fix the damage caused by DiskSalv and FryingPan :admonish:,
the backup I made via Geeks gg:bin/cp is correct except the dates were lost,
I probably should have used the -p flag, otherwise the backup is correct
including Geek's softlinks,
so I just need to copy over the dates, problem is c:list cannot cope with
Geeks softlinks, so I am quickly cobbling together a simplified recursive
c:list program that copes with softlinks (eg skips or lists them etc),
I used this to list out the Bochs subdiretories:
"bochs-20031115"
"bochs-20031115/build"
"bochs-20031115/build/beos"
"bochs-20031115/build/debian"
"bochs-20031115/build/linux"
"bochs-20031115/build/macos"
"bochs-20031115/build/macosx"
"bochs-20031115/build/redhat"
"bochs-20031115/build/win32"
"bochs-20031115/build/win32/nsis"
"bochs-20031115/debug"
"bochs-20031115/disasm"
"bochs-20031115/doc"
"bochs-20031115/doc/docbook"
"bochs-20031115/doc/docbook/development"
"bochs-20031115/doc/docbook/documentation"
"bochs-20031115/doc/docbook/images"
"bochs-20031115/doc/docbook/include"
"bochs-20031115/doc/docbook/user"
"bochs-20031115/doc/man"
"bochs-20031115/docs-html"
"bochs-20031115/dynamic"
"bochs-20031115/font"
"bochs-20031115/fpu"
"bochs-20031115/fpu/stubs"
"bochs-20031115/fpu/stubs/linux"
"bochs-20031115/gui"
"bochs-20031115/gui/bitmaps"
"bochs-20031115/gui/keymaps"
"bochs-20031115/instrument"
"bochs-20031115/instrument/example0"
"bochs-20031115/instrument/example1"
"bochs-20031115/instrument/stubs"
"bochs-20031115/iodev" :juggler:
"bochs-20031115/memory"
"bochs-20031115/misc"
"bochs-20031115/misc/sb16"
"bochs-20031115/patches"
"bochs-20031115/plex86"
"bochs-20031115/plex86/kernel"
"bochs-20031115/plex86/kernel/freebsd"
"bochs-20031115/plex86/kernel/include"
"bochs-20031115/plex86/misc"
"bochs-20031115/bios" :roll:
"bochs-20031115/cpu"
I forget which version of Windows Bochs is trying to reimplement,
@person-regarding-bz2:
the source for bz2 is:
ftp://sources.redhat.com/pub/bzip2/v102/bzip2-1.0.2.tar.gz
which seems to indicate its Redhat Linux,
the contents of "bochs-20031115/iodev" are:
".cvsignore"
"Makefile.in"
"aspi-win32.h"
"biosdev.cc"
"biosdev.h"
"cdrom.cc"
"cdrom.h"
"cdrom_amigaos.cc" :roll:
"cdrom_beos.cc"
"cdrom_beos.h"
"cmos.cc"
"cmos.h"
"crc32.cc"
"crc32.h"
"devices.cc"
"dma.cc"
"dma.h"
"eth.cc"
"eth.h"
"eth_arpback.cc"
"eth_fbsd.cc"
"eth_linux.cc"
"eth_null.cc"
"eth_packetmaker.cc"
"eth_packetmaker.h"
"eth_tap.cc"
"eth_tuntap.cc"
"eth_win32.cc"
"extfpuirq.cc"
"extfpuirq.h"
"floppy.cc" :-D
"floppy.h"
"gameport.cc"
"gameport.h"
"guest2host.cc"
"guest2host.h"
"harddrv.cc"
"harddrv.h"
"ioapic.cc"
"ioapic.h"
"iodebug.cc"
"iodebug.h"
"iodev.h"
"keyboard.cc"
"keyboard.h"
"ne2k.cc"
"ne2k.h"
"parallel.cc"
"parallel.h"
"pci.cc"
"pci.h"
"pci2isa.cc"
"pci2isa.h"
"pciusb.cc"
"pciusb.h"
"pcivga.cc"
"pcivga.h"
"pic.cc"
"pic.h"
"pit.cc"
"pit.h"
"pit82c54.cc"
"pit82c54.h"
"pit_wrap.cc"
"pit_wrap.h"
"sb16.cc"
"sb16.h"
"scancodes.cc"
"scancodes.h"
"scsi_commands.h"
"scsidefs.h"
"scsipt.h"
"serial.cc"
"serial.h"
"serial_raw.cc"
"serial_raw.h"
"slowdown_timer.cc"
"slowdown_timer.h"
"soundlnx.cc"
"soundlnx.h"
"soundwin.cc"
"soundwin.h"
"unmapped.cc"
"unmapped.h"
"vga.cc"
"vga.h"
"virt_timer.cc"
"virt_timer.h"
"vmware3.cc"
"vmware3.h"
:-D :lol: :roflmao:
-
@whoosh777
I'm glad you finally had a chance to play with AROS :-)
Cybergraphics is present and correct. You would have noticed that the AROS graphics are either 65536 or 16.8 million colours (ie true colour) by default. That is why the icons can be very colourful.
If you get a Nvidia (ie GeForce) graphics card you will notice a massive speed up if you select "NVIDIA" at the boot options.
If you press Left-Win + Right-Win and Ctrl keys together AROS will reset (this avoids using the BIOS, so allows for a quicker reset).
AROS can only read Amiga hard drives at the moment, so it can't see your Windows Hard drive. We need a FAT32/NTFS file system driver in order to read the drive.
If you take out the Windows Hard Drive and put a blank drive in there, AROS can format the drive to the Amiga format and you can install AROS onto it.
Once you get a chance to play with the AROS applications and demos in the "Extras" dir of your AROS CD you will see why we are against a slower "big endien" x86 AROS :-) Once you get a taste of Raw CPU speed... you just want more :-D
-
bloodline wrote:
@whoosh777
I'm glad you finally had a chance to play with AROS :-)
Cybergraphics is present and correct. You would have noticed that the AROS graphics are either 65536 or 16.8 million colours (ie true colour) by default. That is why the icons can be very colourful.
is the default WB screen 16.8 million or 65536?
new to such things I dont know the difference,
I had another session today, my A1200 is taking a
trillion years to copy the dates over from the
fried partition so I disconnected it from the VGA
and left it chugging away and had another try with AROS,
hence this reply is via Internet Explorer,
ASAP I want to start browsing via IBrowse,
I found many new things this time, eg the text editor
which has exactly the features I want and does
them better than Memacs: search, search + replace,
tabs remaining as tabs and most importantly bracket alignment:
ie if I type:
tab tab { return
the cursor is aligned with the {, this feature
is vital for the way I write c,
with Memacs I can configure it to do this via
numeric return, but with yours I can use either
return which is much more convenient,
I found so much further stuff this time that
I now think it is very nearly mature,
so I think it can take off without backwards 68k
compatibility,
last night when I tried it out, somehow I didnt
find all the directories,
I still havent found gcc on it, though I found
the includes and gcc libraries, you have a lot
of gcc stuff including libjpeg,
I noticed you have libbz2.a and bzip2, otherwise
I would have ported those, on this machine
it could port instantly. Though something that
ports painlessly on one system may be a major
issue on another,
jpeg is very very portable so it should port to
everywhere very straightforwardly,
If you get a Nvidia (ie GeForce) graphics card you will notice a massive speed up if you select "NVIDIA" at the boot options.
PCWorld had this for £99, is that a good price?
what is the full product name?
Is it A1 and Pegasos2 compatible?
Nvidia vs Radeon? will you eventually have Radeon support?
is it worth me waiting?
If you press Left-Win + Right-Win and Ctrl keys together AROS will reset (this avoids using the BIOS, so allows for a quicker reset).
ok, it was a usage-problem and not a bug,
I take it thats the left control key?
Is there any way I can boot to Windows XP with the
AROS CD still in the drive?
AROS can only read Amiga hard drives at the moment, so it can't see your Windows Hard drive. We need a FAT32/NTFS file system driver in order to read the drive.
can I reconnect my existing SCSI FFS drives to
my new PC SCSI interface and use them AS-IS?
Is there a risk factor as with WinUAE or is it
totally safe?
If you take out the Windows Hard Drive and put a blank drive in there, AROS can format the drive to the Amiga format and you can install AROS onto it.
You are saying that I shouldnt install AROS to this
current internal drive?
I want to try and only use external drives, so I can
selectively switch the power off as a virus precaution,
can I install AROS to some such external drive?
what is the best type of external drive to get?
(low cost + high speed),
Once you get a chance to play with the AROS applications and demos in the "Extras" dir of your AROS CD you will see why we are against a slower "big endien" x86 AROS :-) Once you get a taste of Raw CPU speed... you just want more :-D
It would give you parity with Windows XP,
probably you will even overtake Windows XP for speed,
Its certainly now the fastest Amiga in existence for
the home user, and just as fast as Windows XP,
furthermore its faster than all Macs,
hey everyone I overtook the Macs for under £300,
gloat, gloat, gloat, he he he, :-D
all those debates about Mac vanish,
2 questions on little-endian x86 AROS:
1. Have you a version that runs above Windows?
2. Have you a version of UAE that runs above
either even if its not integrated?
because I may then use that instead of WinUAE
for my 68k environment,
I have some really useful things which can only be
run in 68k,
I tried out some of the Extras programs which looked
very impressive, some of the Windowing is just as good
as Windows XP,
would it be possible to reintroduce an OS1.2 click to back
gadget? maybe via some Prefs program for standard gadgets,
I never liked having to click twice to move an
in between window out of view on OS3,
I noticed your shell has tab completion via requester
exactly the way I want it, is the shell King-con or
have you reimplemented it from scratch??
I didnt check whether you've fixed the square bracket
problem on King-Con, on King con if there are square
brackets in the shell output, if you scroll back to
them they vanish! Thats why I use () in the usage info
in my programs such as the above trackdisk.c,
I used the Prefs programs and managed to change the
background colour of the WB, I forget how I did it
but there were 2 colours with a gradient between these 2,
also you can rotate the direction of the gradient,
I removed the gradient by making the 2 colours the same,
as I dont like prettiness in my interfaces,
I like my interfaces to be rough, ready and functional,
thats why I like Memacs and the AROS editor,
The transparent window with a circle on it looked
really interesting, I want to see what the mechanism
for doing this, non rectangular windows should be now
possible,
Maybe I will write a graphics demo, just a bit of fun,
nothing major,
I want to learn what GPL is as well, is it
"graphics programming language" or what?
(not referring to the Gnu Public License also GPL)
-
@Piru,
the above trackdisk.c program for
moving between disk-binary-files and disks
is an example of what I call disposable-programming,
I encounter a problem that needs fixing real fast,
here it was I had to create a disk from a binary
to boot AROS,
so I didnt want to spend too long on this,
I write different grades of program eg ultra-safe,
safe, ok, unsafe, very unsafe,
this one was ok,
My A1200 system is 14Meg, a sector is a few kb at
most, so those 2 allocations will succeed,
if you are going to do something low level like
bypassing the file system to disk then you shouldnt
push a low memory system,
I think anyway that the OS produces a Ram disk full
requester before it returns failure,
Piru wrote:
#include <pragmas/exec_pragmas.h>
#ifdef LATTICE
#include <clib/exec_protos.h>
#endif
#include <clib/alib_protos.h>
#include <clib/exec_protos.h>
#include <clib/dos_protos.h>
Use:
#include
#include
#include
instead. More portable.
More portable than what?
my code runs on Lattice and gcc,
current machines are all gcc, so I think its as
portable as gcc is,
lots of cross platform c progs dont run on Lattice,
so a lot of programmers out there regard
gcc-compatibility as portability,
my code is as portable as theirs,
int ret = 20;
Use:
int ret = RETURN_FAIL;
later, ret = RETURN_OK; and ret = RETURN_FAIL;
[\quote]
0 and 20 are easier to remember than your symbolic
constants, I can never remember those symbolic constants
and what include contains them,
so to save 5 minutes of searching I use 0 and 20
which are totally correct and easier to remember,
[\quote]
TrackMP = CreatePort( 0 , 0 ) ;
if( TrackMP==0 ){ printf("CreatePort error\n"); goto cleanup ; }
TrackIO = (struct IOExtTD *)CreateExtIO( TrackMP , sizeof( struct IOExtTD ) ) ;
Use CreateMsgPort/DeleteMsgPort and CreateIORequest/DeleteIORequest. Why use amiga.lib when these routines are in exec.library ?
because the RKMs say so,
time is a resource, I dont have the 10 minutes
to search through the docs for some synonym which
may have subtly different usage,
CreateMsgPort isnt in the OS1 RKMs so its not
backwardly compatible,
WriteBuffer = AllocVec( SECTOR_SIZE , MEMF_CLEAR | MEMF_PUBLIC ) ;
geom = AllocVec( sizeof( struct DriveGeometry ) , MEMF_PUBLIC | MEMF_CLEAR ) ;
Allocation can fail. You MUST check for NULL result from AllocVec and act accordingly.
its a small one off allocation,
dont use low level disk progs in a low memory situation,
this program will only fail if you have a few kb in
your WB title bar, the memory overhead really is tiny,
try not to run progs when the title bar says 100000
bytes free memory,
this code was for someone trying to install AROS,
they are in a hurry to get on the PC, they wont be
running major stuff on their A1200 if they are using
this,
its that bible story of the soldiers who drank
directly from the water, vs those who drank from
their hands,
mixing printf and PutStr / Flush
Don't mix stdio and dos.library calls. This won't work properly (output problems due to buffering). Either use only stdio functions or only dos.library functions.
but it runs ok in my compile,
the buffering issue may be irrelevant because of
the newline, if there's a newline the text
gets flushed out before the function returns (I think),
anyway if the sequencing was wrong, its not a big deal,
main thing is that the correct disk is created,
I expect the users to be intelligent enough to
know what
...1..00..byte..s...
means,
anyway POSIX says that i/o API calls should be
indivisible or something,
not my fault if someone flouts sensible indivisibility
and sequentiality to save a few nanoseconds,
printf anyway must be implemented via PutStr,
so if the output of printf and PutStr gets interleaved
as I have seen then someone has blundered and its not
me, so blame the people who made the OS or the compiler,
but dont blame me,
In fact, there is no need to use stdio in the program, just use dos.library and get rid of all stdio stuff. The code will never be portable anyway, so why use stdio?
I use stdio because its easier to remember,
AmigaOS can print integers but I can never remember the
API call, too much effort,
the program runs correctly,
live with the fact,
havent you got anything better to do with your time?
lots of major programs are written much worse than this,
IBrowse often crashes when I launch it if I use Genesis,
it doesnt crash if I use Miami, my Geek environment
often crashes if I simultaneously access from another
shell the directory its looking at,
not always, but quite often,
Windows XP couldnt cope with the fact that I might not
have speakers connected,
When I booted up XP after AROS, Windows queried me about
the AROS CD: "what do you want Windows to do?"
"view a slide show of the images?"
next time I'll click yes!
If I write data from Memacs to another file
it read protects it, which causes all sorts of
problems eg if the partition becomes invalidated
then I cannot read that file to salvage it via
c:copy,
total pain,
the validation problem of AmigaOS disks,
thats not just a bug, thats a design flaw,
the validation problem is a bit like the
towers of Hanoi puzzle, when a new file is
entered into the system it has to be done
in such a way that its only truly integrated
via the last disk write, and if the write fails,
(eg crash or power off) then the file system
should be complete and correct but just missing
that file,
:you would achieve this by having duplicates of
certain datastructures, if the newer datastructure
is inconsistent you would use the older one,
a brute force way to achieve this is by
dividing the disk into 2 identical halves both
with FFS,
then you will always write a file firstly to the
first half and then again to the second half,
if either half is invalidated you would then use
the other half and correct the wrong half,
much more elegant mechanisms should be possible,
and Morphos say their system has fixed the problem,
and has other sensible features such as recursively
updating info up the file system tree,
its a typical architecture design problem,
some architects can design an airport or a city
whereas others dont know how to design a garden shed
DoIO( (struct IORequest *)TrackIO ) ;
IO can fail. You should implement retry (maybe 5 times), and if retry fail, report the error.
again I have done it exactly as in the RKM's,
I have never known DoIO to fail,
and please note that some of the OS calls
have bugged returns, if you pay attention to the
return, your prog will crash,
I have had major program malfunction by paying too
much attention to silly returns,
some AmigaOS API calls tell you how much data
the call processed and its wrong, the call itself
is fine just the return is wrong,
load an autodoc into your editor and do a search
for "bug", there are many,
so it actually pays to ignore the returns
of some of the unlikely failures, I even
have a feeling that DoIO()'s return may be
unreliable, but as I am connected to my PC
I cannot check the autodocs,
its silly to disconnect h/w while its busy,
dont remove the disk if you've just initiated
a binary write, its asking for trouble,
often when I code I patch the memory allocation via:
void *my_alloc( int size )
{
void *mem ;
while(1)
{
char c ;
mem = AllocVec( size , MEMF_CLEAR );
if( mem )break ;
printf("couldnt allocate %d bytes,"
" free some memory and type any key", size ) ;
scanf("%c\n",&c ) ;
}
return( mem ) ;
}
advantage is I dont have to do any error checking,
the error checking being implicit in the call,
that call can only return successfully, only way out
is to type control-C which has an inbuilt exit()
which frees all C resources,
I wish it would also free all OS resources but it doesnt,
it could though,
the OS (or compiler) actually does this to some extent
via a Ram full message,
IMO error returns are a feature of bad design,
error returns should be an option not the default,
you only rarely want an error return eg to
check for existence of a file or memory space,
here the API should really provide an exists( filename) ;
call and a largest_contiguous_memory(); call,
every resource API should provide existence() calls,
doing it via error messages could be inefficient,
I try to keep my mind focussed on higher issues
rather than this sort of nit-picking,
-
How much of hte 970 transistor count is needed for legacy support? Virtually nothing.
Note that PowerPC 970 applies decode/cracking on PowerPC32 ISA before being executed to FRISC** core. Depending on the instructions, 9 stages are allocated for decoding.
**Further Reduced Instruction Set Computing (FRISC).
I'm not sure what sort of bus the Alpha was using then
A few rhetorical questions;
1. What was the clock speed of that particlar DEC Alpha at 1997 against the Pentium Pro?
2. What was the price differential between the two?
3. What was transistor count between DEC's Alpha and Intel's Pentium Pro?
Alpha 21264 EV6 was release in early 90s and it's an example of 3rd generation Alpha.
Note that, the aggressive OOO (out of order) scheme of the Alpha runs counter to the pure RISC ideal. Also note that the Alpha is a six-issue wide pipeline. There's no way for Intel's 'Pentium Pro' can match that (former)beast.
Incidentally, I'm not the one who started the PPC v Intel debate here
Well, you(and other person) opened some issues in relation to PPC and X86.
-
The problem is, it's not a simple linear process where x86 instruction "X" is always decomposed into micro-op codes "a b c". The early stage of decode may work this way but once it has to start processing "a b c", it almost works like a mini compiler, looking to see what rename registers are/will become free, which instructions have dependencies etc. All this takes clock cycles - which is partially why modern x86 CPU's have such very long pipelines and "time of flight" for instructions.
Note that, the PowerPC 970 has 16 stages for integer type instructions, 17 stages for load/store instructions, 21 stages for floating-point instructions, and up to 25 stages for SIMD instructions.
"The depths of the 970’s pipelines vary greatly, depending on the instruction type. All the pipelines begin with nine fetch and decode stages. This large number of initial stages is extraordinary for a classic RISC architecture. It’s more reminiscent of today’s x86 processors".
Why not compare PowerPC 7447A @~1.5Ghz vs PowerPC 970 @~1.6Ghz?
With AMD's K8 processors, completed instructions can exit the pipeline without going thought the rest it. It's estimated that the K8 processors only has 20 stage pipelines (depending on how AMD count its pipelines i.e. pipeline comparison may be comparable with IBM’s way).
Reference
1. IBM PowerPC 970 (http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/A2CE393ABF2CE99787256D21006AE8A2/$file/PPC970_MPF_Review.pdf)
-
I think anyway that the OS produces a Ram disk full requester before it returns failure,
No. It will just crash due to your program writing to zeropage.
More portable than what?
More portable than:
#include
#ifdef LATTICE
#include
#endif
#include
#include
#include
Not to mention easier to remember and shorter to write.
proto/#?.h will work with all amiga and amigalike compilers, instead of just lattice and gcc. Also proto/#?.h will always use optimal features of compiler (inlines instead of stubs on gcc for example).
my code is as portable as theirs,
Don't add non-portability when it can be easily avoided.
Use CreateMsgPort/DeleteMsgPort and CreateIORequest/DeleteIORequest. Why use amiga.lib when these routines are in exec.library ?
because the RKMs say so,
time is a resource, I dont have the 10 minutes
to search through the docs for some synonym which
may have subtly different usage,
CreateMsgPort isnt in the OS1 RKMs so its not
backwardly compatible,
You already crash on OS1.x anyway. V36+ routines you use, without testing for V36+:
- exec/AllocVec
- exec/FreeVec
- dos/PutStr
its a small one off allocation,
dont use low level disk progs in a low memory situation,
These are bad excuses. Crashing under low mem situations is unforgivable. Just test for NULL result.
but it runs ok in my compile,
Another VERY bad excuse.
anyway POSIX says that i/o API calls should be indivisible or something,
Sure. AmigaOS is not POSIX.
printf anyway must be implemented via PutStr,
No. And it's not. Thus the possible problem when mixing stdio and dos.library IO.
the program runs correctly, live with the fact,
It doesn't.
havent you got anything better to do with your time?
Yes. I also try to help beginner programmers, and try to help programmers to avoid basic mistakes. Nothing personal here.
lots of major programs are written much worse than this,
Which is a shame and source of lots of trouble.
again I have done it exactly as in the RKM's
RKRMs are known to take shortcuts all over. You MUST check for I/O errors. Either check result from DoIO() or WaitIO(), or use io_Error field in the iorequest.
, I have never known DoIO to fail,
...Which doesn't mean it never won't. I/O can fail, usually due to bad medium (bad floppy in this case). It is important to tell user if his/her data was not properly read/written.
Load an autodoc into your editor and do a search
for "bug", there are many,
so it actually pays to ignore the returns of some of the unlikely failures, I even have a feeling that DoIO()'s return may be unreliable, but as I am connected to my PC I cannot check the autodocs,
AllocVec() and DoIO() return values are 100% reliable.
its silly to disconnect h/w while its busy, dont remove the disk if you've just initiated a binary write, its asking for trouble,
Which reminds me, your code fails to Inhibit() the filesystem. Anyone accessing the disk simultanously can get corrupt results, even corrupt the written data.
the OS (or compiler) actually does this to some extent via a Ram full message,
No it doesn't. OS will give you NULL ptr.
-
is the default WB screen 16.8 million or 65536?
new to such things I dont know the difference,
The actual colour depth is chosen by you at the boot screen. The 16bit displays have 65536 colours, the 32bit (and 24bit) displays have 16.8 million colours.
There is also a VGA option that is just in case you don't have a modern graphics card, that only has 16 colours.
The Nvidia option defaults to 16bit, and the resolution can be adjusted using the screen mode prefs in the prefs dir.
I found so much further stuff this time that
I now think it is very nearly mature,
so I think it can take off without backwards 68k
compatibility,
We think so too.
I still havent found gcc on it, though I found
the includes and gcc libraries, you have a lot
of gcc stuff including libjpeg,
jpeg is very very portable so it should port to
everywhere very straightforwardly,
gcc is not included in the nightly build, at this time, as there are still issues with it.
All graphics manipulation should be done via the datatypes, so that all programs support all types of file. I belive we already have a jpeg.datatype.
If you get a Nvidia (ie GeForce) graphics card you will notice a massive speed up if you select "NVIDIA" at the boot options.
--------------------------------------------------------------------------------
PCWorld had this for £99, is that a good price?
what is the full product name?
Is it A1 and Pegasos2 compatible?
Nvidia vs Radeon? will you eventually have Radeon support?
is it worth me waiting?
Any Nvidia based card will do for AROS. Just get the best you can afford. I would probably not spend more than £150 on one.
The A1 and Pegasos, are compatible with current AGP specs as far as I know.
We have a couple of people working on Radeon drivers.
Is there any way I can boot to Windows XP with the
AROS CD still in the drive?
if you type e during the GRUB boot stages, and go to the boot console, typing "windows" (IIRC) will boot windows.
can I reconnect my existing SCSI FFS drives to
my new PC SCSI interface and use them AS-IS?
Is there a risk factor as with WinUAE or is it
totally safe?
AROS has no SCSI.device so it can't read SCSI drives. I would be surprised if you PC even had a SCSI connector. you are welcome to write a SCSI.device if you wish though.
You are saying that I shouldnt install AROS to this
current internal drive?
I want to try and only use external drives, so I can
selectively switch the power off as a virus precaution,
can I install AROS to some such external drive?
what is the best type of external drive to get?
(low cost + high speed),
Don't install AROS to your Windows hard drive. AROS will reformat it and turn it into an Amiga Formatted Hard drive.
When AROS gets USB support you will be able to install it onto a USB Memory stick (or USB hard drive) and boot from that. But AROS is still waiting USB drivers.
AROS should be able to read an FFS IDE drive fine.
2 questions on little-endian x86 AROS:
1. Have you a version that runs above Windows?
2. Have you a version of UAE that runs above
either even if its not integrated?
because I may then use that instead of WinUAE
for my 68k environment,
I have some really useful things which can only be
run in 68k,
There is not AROS Hosted for windows, yet. But it will come, people are looking into it.
UAE is included with the nightly build, but the GUI doesn't work yet as Adam hasn't linked it. You will also need to provide an Amiga ROM image as the "Real Amiga" build of AROS needs to be matured.
I tried out some of the Extras programs which looked
very impressive, some of the Windowing is just as good
as Windows XP,
would it be possible to reintroduce an OS1.2 click to back
gadget? maybe via some Prefs program for standard gadgets,
I never liked having to click twice to move an
in between window out of view on OS3,
if you select "Execute Command" and type "opaque" , you will get solid windows :-) You can find the opaque commodity in the Tools dir.
The Click to back gadget was removed because it is redundant. But If you want on, you are welcome to add the code for one, that can be used in different window themes. I will make an OS1.x theme, but I had not planned to include a click to back gadget,
to get better window management, select "Execute Command" and type "clicktofront double" , you will then be able to double click any where on the window to bring it to the front of the dispaly, then hitting the Depth gadget will drop the window in one click :-) You can find the clicktofront commodity in the Tools dir.
I noticed your shell has tab completion via requester
exactly the way I want it, is the shell King-con or
have you reimplemented it from scratch??
I didnt check whether you've fixed the square bracket
problem on King-Con, on King con if there are square
brackets in the shell output, if you scroll back to
them they vanish! Thats why I use () in the usage info
in my programs such as the above trackdisk.c,
KingCon is not used, all features are coded directly into Zune (AROS's version of MUI), and not as third party add on.
The transparent window with a circle on it looked
really interesting, I want to see what the mechanism
for doing this, non rectangular windows should be now
possible,
We have non regular window support, I think there is a demo called "roundwindow" somewhere.
The mechanism for this is built around the standard AmigaOS layers system. But AROS has enhanced the basicly layers abilities.
I want to learn what GPL is as well, is it
"graphics programming language" or what?
(not referring to the Gnu Public License also GPL)
I have no idea what GPL is (other than a Licence)
Also, I recommend you listen to Piru, he knows his stuff!
-
@Piru
I have implemented some but not all of your suggestions,
so if you revisit the earlier posting of trackdisk.c
you will see its been changed,
I have also improved it to read + write any binaries not just
PC disks, but you can feed in any unit of any
device eg trackdisk.device for
AmigaOS df0: df1: etc binaries, and the default is mfm.device for
MSDOS binaries,
some comments:
shell output is now entirely via dos.library,
I wish I hadnt bothered!:
this is a bit of a pain
because I have to use FPrintf to print integers and its nonstandard:
%ld instead of just %d for integers,
I decided to implement that for the hell of it to see how it went,
probably never again,
c's stdio is much easier to remember, it remains for reading + writing
to the binary file, fopen(), fread(), fwrite(), fclose() so easy
and logical to remember and use,
but shell messages via dos.library,
c's stdio and memory routines are very well designed and thought through,
so whenever I can use them I prefer them, however dos.library has some
very useful things,
Now c's printf can check for control-C and then it quits,
however this would leave various AmigaOS resources unclosed,
I could fix this "properly" but its some effort,
so instead I have put in a simple control-E to exit via occasional poll
mechanism,
I didnt use control-C as that may be intercepted by a C compiler,
and I wasnt sure of a portable way of disconnecting control-C,
I do rapid control-E polling by checking the tasks SigRecvd flags, if present
I then do a Wait() which immediately clears the flag and returns,
the program then exits in a controlled way freeing all resources,
you are right about DoIO() error returns: if the disk is AmigaOS
and you read it as a PC disk this causes read + write errors
so I have used your suggestion of try 5 times and then give up,
control-E will also quit it before all 5 attempts have happened,
what was unusual was that the DoIO to read the geometry didnt fail,
maybe that only looks at the drive and not the medium,
it looks like the disk has to be formatted as AmigaOS before you can
read/write an AmigaOS binary, ditto PC, ditto etc,
I left the amiga.lib things in as they function fine,
This code could now be used on an arbitrary unit of an arbitrary
device provided it conforms to trackdisk.device structure,
so I think you can use the device name mentioned in the Devs:
entry for a mounted disk,
BEWARE though that this may produce a ginormous file and
writing may totally zap your drive, so use at your own risk,
:eg if you had a 4Gig disk, it would probably try creating a 4Gig
binary, ie its not just the partition but the entirety,
I used your idea mainly because it simplifies the
code,
I left 0 and 20 unchanged as its much easier to remember,
I find it tiresome continuously searching through endless docs
for unmemorable names and usages, this is why I like stdio,
"r" "w" "a" for read write and append is so easy to remember
rather than ACCESS_READ MODE_READWRITE, MODE_READ, etc,
its easy to use the wrong one if you rely on memory,
moral: strings are more portable and easier to remember than symbolic
constants,
I think the code is now watertight, in that it checks for failure
everywhere (except for eg Output() which is unlikely to fail),
:I did this partly because the code now deals with arbitrary disk
devices eg probably even eg unit 3 of 1230scsi.device,
and partly to stop you growling
-
@Karlos,
question for you:
How do you explain the huge speed of 68k FPUs?
68881 and 68882 are much faster than 68k
(I think, otherwise whats the point?)
but these FPUs are much more than CISC they are VCISC IYSWIM ie
very complicated instruction set chips
Sin, Cos, Tan, Log, etc, there is literally an entire app inside
those FPUs, they even do inverse-cos etc,
(calculators also do all that of course)
(sin x == x - x^3/3! + x^5/5! - x^7/7!... but dealing
with ieee specified errors and large x's eg sin(1000) must be some effort to do in h/w)
perhaps s/w done in h/w is the way to get huge speed,
One other note: 68030 and 68060 are both 50MHz but 68060 must
be 10 x as fast,
:I think this is entirely because of caches as both have almost
identical instruction sets and clock speeds,
thus registers + instruction structure is not the only factor for speed,
cache size + speed I think may be a much bigger factor,
Motorola were always a bit tight fisted with their caches,
eg 68020 has microscopic hardly-worth-it caches,
The point of huge caches is eg that a loop containing a huge switch
statement (as would occur in an emulator) would fit entirely in a cache
causing implausibly fast speeds. Your inner RISC thing is
in someways a cache-ROM IYSWIM, and if its done with special
faster than usual RAM it will probably be unbelievably fast,
-
Now c's printf can check for control-C and then it quits, however this would leave various AmigaOS resources unclosed, I could fix this "properly" but its some effort,
so instead I have put in a simple control-E to exit via occasional poll mechanism, I didnt use control-C as that may be intercepted by a C compiler, and I wasnt sure of a portable way of disconnecting control-C,
This indeed is a problem if you use stdio (output) routines. The only way to avoid this is to use compiler specific ways to disable CTRL-C check, or to drop stdio completely and only use AmigaOS libraries.
do rapid control-E polling by checking the tasks SigRecvd flags, if present I then do a Wait() which immediately clears the flag and returns
if (SetSignal(0, SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}
-
Piru wrote:
Now c's printf can check for control-C and then it quits, however this would leave various AmigaOS resources unclosed, I could fix this "properly" but its some effort,
so instead I have put in a simple control-E to exit via occasional poll mechanism, I didnt use control-C as that may be intercepted by a C compiler, and I wasnt sure of a portable way of disconnecting control-C,
This indeed is a problem if you use stdio (output) routines. The only way to avoid this is to use compiler specific ways to disable CTRL-C check, or to drop stdio completely and only use AmigaOS libraries.
I think it may be possible to hack around it in a
portable way: control C will cause a signal
(possibly SIGBREAK, I'm on the PC so I cant look it up)
so you have to set up a signal handler which
eg sets a flag and then returns in the way
(which I cant remember offhand) which makes
the signal effectively ignored.
If you dont set up a signal handler then you get
the default handler which exits,
I got around the problem via ctrl-E,
note also that ixemul control-C is different from
noixemul control-C, ixemul's responds to control-C
immediately which is the correct way whereas noixemul
and Lattice only notice it
when there's a call such as printf(),
I wish lattice hadnt bothered, Lattice does the
signal handler correctly but the signal waits for
eg a printf before it happens,
:the reason ixemul's approach is better is because
if a program is doing some damage you want it to
halt instantly and not wait till it echoes some text, eg the runaway printer problem,
I prefer c's stdio, AmigaOS is too complicated to
remember and nonstandard, eg %d is 16 bit,
I wondered why FPrintf("%d" ,.. was always printing 0,
one other thing I once thought I would speed up a
program which did huge numbers of small memory
allocations by replacing c's memory allocation
(calloc and free) by exec's (AllocMem with MEMF_CLEAR
and FreeMem), I found to my amazement that
the program was now slower,
so c's standard library can be very efficient,
eg if you want to copy an arbitrary size of memory
you need a very good reason to not use memcpy(),
and it deals correctly with overlapping memory,
one of the reasons I use c's stdio and memory
allocation is that *all* c resources are
automatically freed on program exit regardless of
where or how you exit:
main()
{
char *x = calloc( 100000 , 1 ) ;
FILE *fp = fopen( "xyz" , "w" ) ;
}
the memory allocation x and the file fp will automatically
be freed. If I use AmigaOS:
main()
{
char *x = AllocVec( 100000 , MEMF_CLEAR ) ;
BPTR fh = Open( "xyz" , MODE_NEWFILE ) ;
}
the memory x would be lost from the system,
and the file "xyz" would be unusable till I next boot,
One other thing dos.library has copied a lot of
stuff from c eg FPrintf is clearly copied from c's
fprintf(),
do rapid control-E polling by checking the tasks SigRecvd flags, if present I then do a Wait() which immediately clears the flag and returns
if (SetSignal(0, SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}
ok, there's an obscure way to do it,
not sure I will remember it,
-
one other thing I once thought I would speed up a program which did huge numbers of small memory allocations by replacing c's memory allocation (calloc and free) by exec's (AllocMem with MEMF_CLEAR and FreeMem), I found to my amazement that the program was now slower,
Yes, typical malloc() implementation is faster than direct AllocMem(). Typical malloc() implementation is buffered, it grabs larger chunk from the memory at a time, and gives that back to caller in smaller chunks, much like memory pools of V39+.
so c's standard library can be very efficient, eg if you want to copy an arbitrary size of memory you need a very good reason to not use memcpy(), and it deals correctly with overlapping memory,
memcpy() does not deal with overlapping copies. memmove() and bcopy() do.
Depending on the libc implementation, CopyMem() can be several times faster, however.
if (SetSignal(0, SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}
ok, there's an obscure way to do it,
Yes, peeking task tc_SigRecvd is indeed obscure.
exec/SetSignal() or dos/CheckSignal() is the official way to do it. With CheckSignal() it would be:
if (CheckSignal(SIGBREAKF_CTRL_E) & SIGBREAKF_CTRL_E)
{
}
-
bloodline wrote:
is the default WB screen 16.8 million or 65536?
new to such things I dont know the difference,
The actual colour depth is chosen by you at the boot screen. The 16bit displays have 65536 colours, the 32bit (and 24bit) displays have 16.8 million colours.
There is also a VGA option that is just in case you don't have a modern graphics card, that only has 16 colours.
The Nvidia option defaults to 16bit, and the resolution can be adjusted using the screen mode prefs in the prefs dir.
I dont want 16 bit as its less colours than HAM8,
32 bit via byte per component with one extra byte
possibly unused is the best way to do graphics:
you can read/write an entire pixel in one read/write cycle,
ditto each component,
24 bit via byte per component is next best where
each component is via 1 read/write,
16 bit is no good because its 5 + 6 + 5 bits per
component ie its irregular, 15 bits is regular
however 15 and 16 bits are no good because
its slow to access components: shift + mask,
15 and 16 bit are good for reading an entire pixel,
but bad from the component POV,
I found so much further stuff this time that
I now think it is very nearly mature,
so I think it can take off without backwards 68k
compatibility,
We think so too.
you will need to sort out the browser though,
as you operate through the internet,
how difficult is it to implement the TCP/IP stack,
its one area I know nothing about,
I still havent found gcc on it, though I found
the includes and gcc libraries, you have a lot
of gcc stuff including libjpeg,
jpeg is very very portable so it should port to
everywhere very straightforwardly,
gcc is not included in the nightly build, at this time, as there are still issues with it.
All graphics manipulation should be done via the datatypes, so that all programs support all types of file. I belive we already have a jpeg.datatype.
darn! I have to read up about datatypes then,
will you have datatypes for sound then?
its a similar concept,
If you get a Nvidia (ie GeForce) graphics card you will notice a massive speed up if you select "NVIDIA" at the boot options.
--------------------------------------------------------------------------------
PCWorld had this for £99, is that a good price?
what is the full product name?
Is it A1 and Pegasos2 compatible?
Nvidia vs Radeon? will you eventually have Radeon support?
is it worth me waiting?
Any Nvidia based card will do for AROS. Just get the best you can afford. I would probably not spend more than £150 on one.
The A1 and Pegasos, are compatible with current AGP specs as far as I know.
We have a couple of people working on Radeon drivers.
I may wait a bit then, I have lots of figuring out
to do on this new machine,
Is there any way I can boot to Windows XP with the
AROS CD still in the drive?
if you type e during the GRUB boot stages, and go to the boot console, typing "windows" (IIRC) will boot windows.
this is useful info,
I will try this out,
can I reconnect my existing SCSI FFS drives to
my new PC SCSI interface and use them AS-IS?
Is there a risk factor as with WinUAE or is it
totally safe?
AROS has no SCSI.device so it can't read SCSI drives. I would be surprised if you PC even had a SCSI connector. you are welcome to write a SCSI.device if you wish though.
its probably too early for me to attempt a h/w device,
I've just landed on Mars, so I need to do simple minded
things first,
BTW I think scsi.device is quite simple from exec's POV,
all the work is in the 3rd party h/w: interface +
devices making life very easy for the
programmer and OS people,
its just essentially 2 arrays from exec's POV, command and data, command will be eg 6, 10 or 12 bytes for SCSI-3
(I think, several years since I last looked at this)
exec only needs to know size of command and data (I think),
first the interface transmits command to the h/w,
which eg says "write 1000 bytes starting at position 100",
then the interface transmits "data" which will be the
1000 bytes, everything is transmitted independent of
endianess, most significant byte first ISTR,
thats it, "command" itself may be very complicated eg
for CD-R's, but that is the remote h/w's problem
not exec's,
the great thing about SCSI is it abstracts the
driver problem, its also backwardly and forwardly
compatible,
:you can run a SCSI-3 device from a SCSI-2 interface,
and vice versa, (I think!)
on my A1200 I can connect I think 12 SCSI devices
as I have 2 SCSI interfaces, Blizzard SCSI and
Squirrel SCSI,
you never run out of slots,
try connecting 12 IDE drives to an A1200!
and IDE is just Hard disks isnt it??
SCSI is Hard disks, printers, scanners, D-R, CD-RW, DVD-R, DVD-RW, etc,
:I think at least 10 device classes,
The engineering behind it is very complex,
eg you can have X--Y--Z--computer and switch off Y
while in use and the messages continue no probs
between X and the computer,
You are saying that I shouldnt install AROS to this
current internal drive?
I want to try and only use external drives, so I can
selectively switch the power off as a virus precaution,
can I install AROS to some such external drive?
what is the best type of external drive to get?
(low cost + high speed),
Don't install AROS to your Windows hard drive. AROS will reformat it and turn it into an Amiga Formatted Hard drive.
When AROS gets USB support you will be able to install it onto a USB Memory stick (or USB hard drive) and boot from that. But AROS is still waiting USB drivers.
AROS should be able to read an FFS IDE drive fine.
install it onto a Memory stick!
can you get external IDE's?
booting AROS from CD suggests AROS understands the CD,
how does it manage that?
2 questions on little-endian x86 AROS:
1. Have you a version that runs above Windows?
2. Have you a version of UAE that runs above
either even if its not integrated?
because I may then use that instead of WinUAE
for my 68k environment,
I have some really useful things which can only be
run in 68k,
There is not AROS Hosted for windows, yet. But it will come, people are looking into it.
UAE is included with the nightly build, but the GUI doesn't work yet as Adam hasn't linked it. You will also need to provide an Amiga ROM image as the "Real Amiga" build of AROS needs to be matured.
ok, I have to look into this UAE,
can it be used without the GUI?
I have a real Amiga for the ROM image,
I tried out some of the Extras programs which looked
very impressive, some of the Windowing is just as good
as Windows XP,
would it be possible to reintroduce an OS1.2 click to back
gadget? maybe via some Prefs program for standard gadgets,
I never liked having to click twice to move an
in between window out of view on OS3,
if you select "Execute Command" and type "opaque" , you will get solid windows :-) You can find the opaque commodity in the Tools dir.
The Click to back gadget was removed because it is redundant. But If you want on, you are welcome to add the code for one, that can be used in different window themes. I will make an OS1.x theme, but I had not planned to include a click to back gadget,
to get better window management, select "Execute Command" and type "clicktofront double" , you will then be able to double click any where on the window to bring it to the front of the dispaly, then hitting the Depth gadget will drop the window in one click :-) You can find the clicktofront commodity in the Tools dir.
sounds like I will be doing both of these,
on XP there is a problem: I bring a small window
to the foreground to see whats on it to copy into a big window,
problem is the moment I click on the big window to
activate it, it is brought to the front obscuring the
small window which I am trying to read,
takes quite a bit of effort to have the small window
in the foreground with the big window active so it
can be typed into,
I regard this as a design flaw, single clicking should
not depth arrange a window except if the click is on a
gadget,
I need to be able to activate a window without altering
its depth, so I need double-click-to-front,
I noticed your shell has tab completion via requester
exactly the way I want it, is the shell King-con or
have you reimplemented it from scratch??
I didnt check whether you've fixed the square bracket
problem on King-Con, on King con if there are square
brackets in the shell output, if you scroll back to
them they vanish! Thats why I use () in the usage info
in my programs such as the above trackdisk.c,
KingCon is not used, all features are coded directly into Zune (AROS's version of MUI), and not as third party add on.
MUI is 3rd party,
I found Zune very confusing, very difficult to find
what I want on it,
I prefer the other Prefs programs,
direct + uncluttered + self-explanatory + useful,
unpretentious with no bloat,
usually the Prefs settings I want are:
screen colour(s),
keyboard delay + repeat,
keyboard,
mouse speed,
screen fonts:
(I like big fonts: topaz-8 on a 640 x 256 size,)
screen resolution (I find all fonts wrong on
the very high resolutions so I may use a lower
res eg 640 x 256 screen just to get the fonts
right.)
This is a subjective point but I think
a Prefs programs name should be a self-descriptor,
so Prefs/Mouse and Prefs/Palette etc are exactly
what the name says,
eg Prefs/Serial is for setting the serial port,
but Prefs/Zune, who or what is Zune and why
should I want to change it?
why not
Prefs/ScrimbleZooplig
?
Zune sounds a bit pretentious,
In fact on my first trial of AROS, I tried all
sorts of Prefs progs but not Zune because
the name is a nondescriptor,
I think it would be much better to divide Zune into lots
of small Prefs programs eg Prefs/String_gadget,
somehow (probably from clicking the wrong buttons
on Zune) I got my icons text with white text in a
black outline, I wanted to change this to
usual black text with no outline,
I could not do it, I also was unable to refind
how to change the screen colour. I found it once
but never again and I went around in circles
through Zunes incomprehensible options,
eventually I got fed up and started looking at other
directories instead,
whats wrong with just having Prefs/Palette
or Prefs/Screencolour?
I'm sure Zune can do the above 2 things,
but I gave up trying to find how,
Zune is the only part of AROS which is more
confusing than Windows XP,
Is there an API or full documentation for the prefs?
maybe I will write a shell command:
set_screen_colour r g b
please dont tell me the screen colour is in a file
zune.prefs, oh no, it is isnt it?
In that case I give up!
The transparent window with a circle on it looked
really interesting, I want to see what the mechanism
for doing this, non rectangular windows should be now
possible,
We have non regular window support, I think there is a demo called "roundwindow" somewhere.
The mechanism for this is built around the standard AmigaOS layers system. But AROS has enhanced the basicly layers abilities.
I'll look out for this and try it out,
I can see that nonrectangular windows are going to be
a bit too much of an effort to code,
I think the transparency is a more practical feature
than nonrectangular windows,
I have to try out click to front on the
transparent region, see if I have to click on
the visible part,
-
16bit is much better than HAM. HAM is slow, and is only suitable for stationary graphics. Each pixel gets two of it's colour components from the pixel to the left. This requires a massive amount of CPU time to work out.
The human eye is able to see twice as many Green Shades as Red shades so it makes sense to have the 5+6+5 RGB arrangement.
All camera have to have twice the number of Green cells as Red and Blue.
The TV signal devotes most of it's bandwidth to the Green component, and only a a tiny amount to the Blue component.
You eyes almost certainly can't see all 65536 colours that 16bit graphics can produce.
Remember that if you select a 16bit only the final dispaly is 16bit, the internal graphics operate at much higher bit depths. AROS actually uses 32bits for each colour component!
TCP/IP stacks are hard, but Wez is working on one.
Did you not use Datatypes on your Amiga?
The concept is simple. You write a music player program for example. You don't need to know anything about WAV's or MP3's or IFF's or OGG's, all you need to know is the datatype API.
Then the User can install an mp3.datatype or a wav.datatype etc, and your program can use them. No extra work on your part.
You seem hung up on SCSI. SCSI is a very old idea. Hard drives and CD/DVD drives all go on the IDE bus, all other devices go on the USB or the Firewire bus.
AROS can use CD/DVD drives, because AROS has an ide.device.
SCSI is dead, no normal computer equipment use it :-)
IDE's big limitation is the number of devices it can support, which in a normal computer is 4.
IDE is being replaced with S-ATA (which uses the same drivers as IDE, so AROS will support it) but supports more drivers and better speeds.
UAE is usable in AROS, even with out the GUI, you just need to set the configuration in the config text file. You can get the Amiga ROM image from your Amiga.
The thing I hate most about all GUI's is "auto rise", that is when you single click on a window and it is brought to the front of the display. I hate it. AROS does not do this, and I like it that way :-)
MUI is third party for AmigaOS, but Zune is not 3rd party for AROS. Zune is an integral part of AROS. Zune replaces intuition as the window manager (though Zune uses intuition).
It might seem hard to understand, but what you are seeing the whole Zune prefs, You will probably never need to use the Zune prefs (if you are happy with the AmigaOS3.1 look), but Zune gives you the option to change every aspect of the GUI. It allows you to chance how the GUI behaves and provieds advanced features like, list views, and special gadgets, help bubbles etc... if you want them, if not then just ignore it.
It also makes writing GUI's for programs much easier.
As for the name, Zune, I had a vote for a new one, but Zune was chosen, the public spoke, so we kept the name.
You set the screen colour/pattern/gradient/pitcture using the prefs program for that (the name escapes me). You do not use Zune Prefs for that.
Zune Prefs are not something you need to concern yourself with if you don't want to, zune manages the interface regardless (You can still use intuition if you wish, when programming, but for anything other than a simple app, you will be making work for yourself).
I think the transparency is a more practical feature
than nonrectangular windows,
I have to try out click to front on the
transparent region, see if I have to click on
the visible part,
Yes transparency is a more useful feature than nonregualr windows, but nonregular windows are useful for window themeing, some people like themed windows.
The transparent part of the window is not clickable, and events there will go through to the visible window/screen below. You should think of a trasparent region as not part of the window at all!
-
Hammer wrote:
A few rhetorical questions;
1. What was the clock speed of that particlar DEC Alpha at 1997 against the Pentium Pro?
I already said. The alpha system there was a single processor set up at 266MHz. The Pentium-II machines brought in as 'upgrades' were 350MHz.
2. What was the price differential between the two?
Not entirely sure. Both systems were expensive, using SCSI, custom designed cards etc., but the alpha had been kicking around in the lab for several years already. The Pentium-II machines were brought in to replace it for 2 reasons:
1) Future versions of the software for which the machine was used were to be for x86 only, a move to sell it to a potentially larger audience (no doubt), so a shift to x86 was unavoidable. It was decided to make the shift early to lessen the upgrade hassles later.
2) The Pentium-II 350 machines brought in were expected to outclass the older Alpha @ 266.
Embarassingly for the senior IT technician who ordered the changes, the newer machines ran the existing x86 version of the software not only slower than the Alpha, they ran it at a speed that was only marginally greater than running the x86 version under FX32 on the alpha.
Pity they ain't still making them :-(
-
@bloodline
Actually, the normal human eye can differentiate several million shades. Even with my colour blindess I can see that undithered 16-bit images are visibly considerably lower quality than 8-bits per gun. Many display cards often use 10-bit resolution (or higher) per gun for their DACs.
However, if you use dithering on 16-bit image data (when reducing down from 24/32-bit), the quality is dramatically improved.
@whoosh777
As bloodline says, HAM8 is slow as hell. It's only tha amiga's unique hardware arrangements that makes it even remotely feasable as a display mode at all. Even then its really only useful for showing still images (including frames of animation). It's not especially useful at all for 'realtime' imagery as generated by GUI's etc. Trust me, there's nothing it can visually do that can't be outclassed by a genuine 32-bit display running even on a fairly low end card.
-
@Hammer
>Well, you(and other person) opened some issues in relation to PPC and X86.
I think I touched a raw nerve by saying IBM dont know how to design CPUs,
Karlos pointed out that PowerPC is an IBM thing and not a Motorola thing,
in which case why has the Amiga taken on an IBM CPU???
@Piru
>No. It will just crash due to your program writing to zeropage.
this problem is easily fixed by:
1. moving the vbr away from the start of memory, as in fact appears to happen
if you run "cpu fastrom", Sysinfo shows where the VBR is,
2. the OS should then write protect the first page of memory after the
pointer to ExecBase has been set up in position 4,
Now when my prog tries to read from disk or file to position 0 the MMU will
intercept this and a "first page write violation" requester should come up,
"click to remove task",
as all its reads begin at the start of the array zero problems would result,
its not my fault if the OS designers put the most critical
OS vectors right above 0,
BTW my program with device set to trackdisk.device creates uncompressed .adf
files, I found this by comparing its output to that of something from
www.aminet, in trying to set up WinUAE,
I have set up WinUAE now with AIAB, its absolutely fantastic and its
the identical ROM of my A1200 so its the real AmigaOS,
so the XP machine is like a huge graphics card accelerator for my ROM,
It has the exact same quality as the Windows XP environment,
as its basically an XP app, with emulated Picasso screen,
the speed tests were absolutely staggering: it filled an entire screen
with characters instantly, it was like rain in a thunderstorm,
it said equivalent to 1662 MHz 020 and 5234 MHz FPU,
100 x speedup of FPU!, 30 x speed up of CPU (I think)
361 MIPS, 673 MFlops, I havent run Sysinfo yet,
There are some font render bugs, I ran Memacs with a large font and it doesnt
quite erase a character if you type del, so you end up with a lot of
detritus in the bitmap,
There seem to be long delays from double clicking an icon till it runs,
but once it runs it moves like greased lightning,
The way WinUAE deals with hard-drives and floppies is they are
files on the Windows drive, so the hard drives on the WB seem to be
the subdirectories of a particular directory on XP,
thus to transfer Amiga files over you just copy them over on Windows into
those subdirectories,
the AIAB backdrop is visually more stunning than any of XP's also the
AIAB icons + icon text are actually better than XP's if you like that
type of icon,
the amount of graphics ram seems a bit limited though, its either 8 or 16 MB,
(I forget which),
AROS should be much faster still, they say power is an aphrodisiac,
I think once any developer starts coding on AROS they are going to become
totally hooked,
>Sure. AmigaOS is not POSIX.
I'm not advocating POSIX, gcc is largely
POSIX compliant, so AmigaOS is very nearly compliant,
what I meant was that indivisibility and sequentiality are crucial
design features, its very pedestrian if 2 i/o API calls of the same
Task violate this, ie Putstr(...) ; printf(...) ;
its no use blaming the programmer, both those calls dont reference any
resources so it should be safe to call them both,
>>printf anyway must be implemented via PutStr,
>No. And it's not. Thus the possible problem when mixing stdio and dos.library IO.
printf is dos.library IO:
I wrote a small simplified version of SnoopDOS, I give it any jump vector
and when I type control-E it tells me how often its been used,
this tells me:
SAS C 650 and 68k gcc *both* implement printf() via dos.library Write(),
probably printf(...) is implemented via fprintf( stdout , ...) which
in turn calls Write()
buffering should be inbuilt at a low level,
dos.library buffering sucks with titchy static buffers per drive,
(c:AddBuffers) buffers should be dynamically allocated at use time and
they should be big it makes a big difference to performance,
most drives most of the time are asleep so if you have 10 partitions
that is say 8 asleep buffers, its so wasteful,
it annoys me when people vent their anger at me for what is really an
architectural flaw, I will redirect that anger to where it rightfully
belongs though,
this is how I would implement PutStr() :
int PutStr( UBYTE *str )
{
int len ;
len = strlen( str ) ;
if( len==Write( Output() , str , len ) )return( 0 ) ;
else return( -1 ) ;
}
ooh that was difficult,
my prog tells me they havent used any of Write(), FPuts(), VFPrintf(),
>Which reminds me, your code fails to Inhibit() the filesystem.
>Anyone accessing the disk simultanously can get corrupt results,
>even corrupt the written data.
I suppose you take out an insurance policy every time you cross the road??
I used it quite painlessly to turn my WB3.0 floppy into an ADF file
and it boots quite fine to WinUAE, smooth as clockwork,
you should take a stroll down www.aminet sometime,
its "storm in a teacup" time,
some people get their kicks by being unconstructive,
but the constructive people always win in the long run,
-
I have set up WinUAE now with AIAB, its absolutely fantastic and its
the identical ROM of my A1200 so its the real AmigaOS,
so the XP machine is like a huge graphics card accelerator for my ROM,
It has the exact same quality as the Windows XP environment,
as its basically an XP app, with emulated Picasso screen,
the speed tests were absolutely staggering: it filled an entire screen
with characters instantly, it was like rain in a thunderstorm,
it said equivalent to 1662 MHz 020 and 5234 MHz FPU,
100 x speedup of FPU!, 30 x speed up of CPU (I think)
361 MIPS, 673 MFlops, I havent run Sysinfo yet,
Sounds like you made the right hardware choice for your needs :-)
AROS should be much faster still, they say power is an aphrodisiac,
I think once any developer starts coding on AROS they are going to become
totally hooked,
Exactly! :-D
-
WinUAE vs A1200 Sysinfo speed comparison,
Windows XP, CPU = 2.600 GHz Intel Celeron,
256 MB RAM, 64MB shared memory Intel graphics card
WinUAE via AIAB Picasso emulation,
AGA A1200: 50MHz 68030 + MMU, 50MHz 68882 FPU,
CPU: 972 MIPS vs 9.01 MIPS : 108 x faster
FPU: 331 MFlops vs 1.33 MFlops : 249 x faster
Dhrystones: 931824 vs 8632 : 108 x ratio,
so CPU is some 100 x as fast, and FPU is 250 x as fast,
there you have it, certified FUD free,
AIAB comes with a different speed program Sysspeed,
that said: 361 MIPS, 673 MFlops, but its not fair
to compare Sysspeed on WinUAE with Sysinfo on A1200,
so I will try a Sysspeed comparison also,
You can tell WinUAE to treat a particular XP directory as
a hard disk, floppies are via .adf files which you can
create via my trackdisk program earlier, set
device to be trackdisk.device
Once I've got myself more organised I'll do my own
speed comparison of AROS vs WinUAE, but not via
Sysinfo etc but via a "real" program of some sort,
test programs are a bit artificial,
I will try and compare progs that run entirely in RAM
to remove disk speed from the comparison,
-
@whoosh777
No. It will just crash due to your program writing to zeropage.
this problem is easily fixed by:
1. moving the vbr away from the start of memory, as in fact appears to happen if you run "cpu fastrom", Sysinfo shows where the VBR is,
2. the OS should then write protect the first page of memory after the pointer to ExecBase has been set up in position 4,
...except that device read access can use DMA to write to memory (KS 1.x trackdisk.device always uses blitter to decode, KS 2.x+ trackdisk.device doesn't since !(TypeOfMem(0) & MEMF_CHIP), dunno about mfm.device). If DMA access is used, it is not captured by MMU. Reading to address 0 could happily overwrite whatever data is at address 0 and forward, regardless of MMU. However, if the zeropage is mapped to fastmem, the fastmem copy will not be trashed (so ExecBase ptr would remain valid). Anything in low chipmem would be trashed however (readlen > chipmem start address), including the chipmem MemHeader, leading to swift crash (next memory allocation/deallocation).
Now when my prog tries to read from disk or file to position 0 the MMU will intercept this and a "first page write violation" requester should come up, "click to remove task",
Might not happen if the read access uses DMA (see above).
Even if the app crashes, there is no way to "remove task" safely, since there is no resource tracking or separated address spaces. When task/process crashes under AmigaOS the safest thing you can do is make it Wait(0) (suspend).
Now, it might be just my twisted personality, but IMO it would make much more sense to check for allocation failure rather than worry about all this.
printf is dos.library IO:
SAS C 650 and 68k gcc *both* implement printf() via dos.library Write(),
True. dos.library VPrintf() calls VFPrintf() for Output() filehandle. VFPrintf() calls RawDoFmt() with FPutC() putchproc that will eventually use Write() to write the chars. How much is written at a time depends on the filehandle buffering mode (BUF_LINE == Write() is used when newline is reached, BUF_FULL == Write() is used when buffer fills up or BUF_NONE == Write() is used for every char). See dos/SetVBuf().
this is how I would implement PutStr() :
int PutStr( UBYTE *str )
{
int len ;
len = strlen( str ) ;
if( len==Write( Output() , str , len ) )return( 0 ) ;
else return( -1 ) ;
}
ooh that was difficult
But it also lacks all local buffering. It doesn't handle BUF_NONE and BUF_LINE properly. With such methods all buffering would be left at the lower level (filesystem and device driver), thru several APIs. The "closer" the buffering is to caller, the faster it is. Also when the buffering is local it has much better knowlege of the actual buffer usage, so further optimizations are possible that would not be at lower level.
my prog tells me they havent used any of Write(), FPuts(), VFPrintf(),
Your snoop program probably only tells you if something calls dos.library thru vectors. It doesn't detect dos.library calling itself directly via bsr or jsr. Also it misses direct DosPacket I/O to filehandler (for example ixemul uses it).
All dos.library, SAS/C libc & GCC ixemul and GCC libnix libc use similar buffering methods, fgetc for reading data and fputc for writing.
-
Embarassingly for the senior IT technician who ordered the changes, the newer machines ran the existing x86 version of the software not only slower than the Alpha, they ran it at a speed that was only marginally greater than running the x86 version under FX32 on the alpha.
"Figure 1 shows the relative performance on the ByteBenchmark of a 200Mz Pentium Pro and a 500 MzAlpha running DIGITAL FX!32. For this benchmark,the Alpha running DIGITAL FX!32 provides about thesame performance as a 200Mz Pentium Pro"(1)
References
1. http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf
2. http://www.hotchips.org/archive/hc9/hc9pres_pdf/hc97_4b_rubin_1up.pdf
-
@Hammer
I have no idea about the bytmark benchmarks but they aren't relavent to the point I was making. All I can tell you is the software in question was for spectra prediction and molecular energy calculations. There were several different platform builds available at the time, but it was stated that future versions would be x86 only. The existing x86/NT version ran very poorly on the real Pentium-II compared to the same revision for Alpha, which managed to run same the x86 version around 80% of the speed at which the Pentium-II did. The Alpha native version on alpha comared to the x86 version on Pentuiu-II was about 2x faster. That's all I can tell you.
It seems to me in hindsight that the x86 build of that version of the application must have been very poor.
Hell, I didn't write the stupid thing, I just had to use it.
-
@Karlos
Note that there are two versions of Alpha @~266Mhz
1. Model 21066 (2 issue superpipeline, EV4 core)
2. Model 21164 (4 issue superpipeline**, on chip ~96KB L2 cache, EV5 core). **2 integer pipelines, 2 floating-point pipelines.
The Model 21064 was release around March 1992, sports a 128-bit bus interface.
The first Pentium II variant to received it’s on chip L2 cache is during introduction of Celeron 300A (Mendocino).
Other related references (X86 complier improvments)
http://www.aceshardware.com/Spades/read.php?article_id=40000191
-
@Hammer
Interesting. The Alpha machine was there in 1995 and wasn't new then. I'm reasonably sure it was a 21164. When was it released?
-
@Karlos
"FMUL and FDIV that are still 'not pipelined' in the Pentium III. "(3).
Reference.
3. http://www.heise.de/ct/english/99/16/092/
Interesting. The Alpha machine was there in 1995 and wasn't new then. I'm reasonably sure it was a 21164. When was it released?
Around 1994 for Alpha Model 21164 (industry’s first 300Mhz processor)(4). ~266Mhz variant could be the slightly cheaper version.
Reference
4. http://vt100.net/timeline/1994-3.html
-
@bloodline
if I have understood you right AROS understands IDE
and AmigaOS so I think I will set up an IDE AmigaOS
drive for AROS, I have to think a bit how to go about
this.
I installed my first hardware yesterday: I opened up
the box and installed the Fast SCSI-2 PCI interface,
this was totally painless, the box internally is
very well engineered, lots of space, slots wherever
you look: 3 PCI slots with one used by the modem,
PCI modem sounds a bit extravagant, so I have 1 PCI
slot free now,
I suppose an unused slot is a wasted slot in some sense,
I noticed a similar but different slot which must be
the AGP slot for Gfx card??
Also 2 Simm slots with one in use, which must be the
DDR RAM, 256 Mb currently,
There is a free IDE-drive place which I may use for
AROS or I will reuse the current drive: but I would
have to transfer its contents first: where to???
there are also 1 unused floppy + 1 unused optical drive slots.
I figured out most of it just by looking eg the existing
PCI slot puzzled me, is that a drive? until I noticed that the phone socket was part of it, aha! its a modem!
its great how the SCSI socket is on the back of the case,
so conveniently thought out,
I have already downloaded my first Spyware/adware,
it seems I should have read the EULA, Norton located
the 3 problem files,
The security risk on this machine worries me a bit,
this is why I want to use external drives:
not just to prevent viruses but to prevent MS spying on
my system. This system is so complicated that they
could do anything they want and you wouldnt be any
the wiser. The spyware info says that spyware already
can raid your system for passwords, address books etc
So I want multiple unconnected environments:
drives X,Y,Z,... where 2 of these are never simultaneously
on and communication is done via ascii only floppy disks
or something like that. I can vett the floppies via my
A1200,
I want my own programming work never to be on an online
machine,
I have to say that buying this PC is the best decision
I have made in the last 10 years, I feel so excited about
it, I have no regrets and am glad I made the break with
Hyperion + Eyetech. The word for me which sums up
those 2 companies is "contempt".
The PC market is so dynamic that its frightening, there is something very liberating about
this machine. Also I want to remain with the Amiga,
when I switch over to my A1200 I can move so much
faster and painlessly. There is something very
direct about the Amiga paradigm, you have immediate
access to everything, on the PC you have to go through
a maze to access anything.
Anyway I cannot wait to find out directly how fast
AROS is, ie how much faster than WinUAE,
if its just 2 x as fast that would make it 216 x as
fast as my A1200,
each 1% speed up would be another A1200! :lol:
at that point I will then be able to quantify the
decision of little endian gcc, big endian gcc
I can also evaluate via Amithlon's big endian gcc,
but thats further down the line,
Once I am set up with gcc I will start on this,
I think I have to sort out the AROS drive first,
because at the moment when I boot up AROS I just
get the CD's icon + RAM icon, so all my work
will evaporate after the session!
:so I can only try out progs that I write in the session,
whats the best way to get files to and from AROS?
because it looks tricky currently,
the original idea of this thread I think is fully
valid, because WinUAE is no use for non Amiga people:
they would have to buy Cloanto to use it:
an AROS kickstart ROM would enable everyone to use
WinUAE for free as well as publicise your project,
furthermore they would be able to use the full
Windows XP through UAE. So people could use
scsi + internet until you have the native
versions up and running (I think),
you mentioned about UAE's GUI, WinUAE's GUI is a
total pain, it has 3 rows of buttons and everytime
you click a button all the other buttons rearrange,
so its very difficult to be certain you've gone
through all the options, its like one of those
sliding square puzzles,
-
@Piru,
I dont want to get too bogged down in the discussion of trackdisk.c,
its just a small utility,
you insert disk, type shell command, wait a little while,
binary ready,
its not a big issue, I am worried that you make such heavy weather
over such a non issue,
but on this occasion I'll look at some of the points you raise,
>this problem is easily fixed by:
>1. moving the vbr away from the start of memory, as in fact appears to happen if you run "cpu fastrom", Sysinfo shows where the VBR is,
>2. the OS should then write protect the first page of memory after the pointer to ExecBase has been set up in position 4,
>>...except that device read access can use DMA to write to memory
>>(KS 1.x trackdisk.device always uses blitter to decode,
>>KS 2.x+ trackdisk.device doesn't since !(TypeOfMem(0) & MEMF_CHIP),
>>dunno about mfm.device). If DMA access is used, it is not captured m
>>y MMU.
ok that bypasses 2. of my idea but only for OS1,
1. I think is sound except for 68000 which doesnt have a VBR,
so the idea is sound on a 68030 MMU machine, 1. is sound on 68020 upwards,
and 2. is sound on MMU machines OS2 upwards,
I think we see here several design flaws: putting the vectors right at start
of memory: the whole situation is ridiculous from a logical POV:
AllocMem() returns 0 on failure,
but 0 *is* a valid memory address,
then putting the highest system data here,
we have here a recipe for disaster: memory allocation failure
returning a valid memory pointer to the most important system data,
guess what the cat-in-the-hat will do here??
really memory allocation failure should return a pointer to non memory which
would cause an exception on *all* CPUs,
preferably a pointer to the middle of a large non memory
region,
-1 may also be a clever way to do it because firstly it is probably beyond
many address spaces, even if it is in the address space it would often cause a
memory alignment exception, non byte accesses would cause exceptions,
I havent used the blitter for a long time but what happens if you give
the blitter an odd address, do you get an exception or just a horrible crash??
lastly not sure about this but it may cause an
exception for wrapping around memory ie after 11111....111111 comes 000...000000
(only if you write from the start,
>>Reading to address 0 could happily overwrite whatever data is at
>>address 0 and forward, regardless of MMU. However, if the zeropage is
>>mapped to fastmem, the fastmem copy will not be trashed
>>(so ExecBase ptr would remain valid). Anything in low chipm
>>em would be trashed however (readlen > chipmem start address),
>>including the chipmem MemHeader, leading to swift crash
>>(next memory allocation/deallocation).
they should have put the memory headers at the end of the blocks,
:memory writes tend to move upwards through memory which makes the
start of memory regions vulnerable to trashing,
as I said I can turn all the criticisms of my code around into
criticisms of the system design, both h/w and OS,
I think we also see here one of the flaws of in-place memory datastructures,
(ie where the memory regions are self describing data structures),
it may be better to put memory datastructures away from the memory itself
and in write protection,
if its in place put it at the top of the regions,
with exec's struct Library's the jump vectors precede the Library which
is a clever idea,
IMO a well designed system is idiot proof,
dont blame the user blame the designer,
In the Modula3 language you can write code that never checks for errors,
errors always cause lightweight language level exceptions so it produces very
clean code eg instead of
[code]
if( y==0 ){ printf("error in y"); exit(20); }
if( z & ~(MEMF_CLEAR | MEMF_FAST | .... ) )
{
printf("error: undefined memory flag" ) ; exit(20);
}
t = AllocMem( x/y , z ) ;
if( t==0 ){ printf("memory allocation failed" ) ; exit(20); }
[\code]
you would just write:
[code]
t = AllocMem( x/y , z ) ;
[\code]
failure at any of the 3 places would cause the appropriate exception,
so you get much more transparent programs,
its a long time since I used m3 but I think if you dont put any
exception handlers the program will probably just quit with untrapped exception,
>Even if the app crashes, there is no way to "remove task" safely,
>since there is no resource tracking or separated address spaces.
if you had just memory tracking then you could remove the tasks
allocated memory + code + stack,
>When task/process crashes under AmigaOS the safest thing you can do is make it
> Wait(0) (suspend).
thats what I meant, or remove permanently the struct Task from the task queues,
>But it also lacks all local buffering. It doesn't handle BUF_NONE and
>BUF_LINE properly.
you are clouding the issue with implementation specifics,
>With such methods all buffering would be left at the
>lower level (filesystem and device driver), thru several APIs.
no no no, I am standing at the opposite side:
you------prog------API-----API--------h/w-----me
from my POV through 0 API's, from your POV lots of them,
I am looking at it from the h/w POV, you from the programmer or user POV,
speed is determined by the h/w,
>The "closer" the buffering is to caller, the fasterl
>it is.
correction: closer buffering is to the h/w the faster it is,
see CPU caches for example,
caller caching of memory is going to be very slow and complicated,
h/w caching (ie lowest level possible) is much faster than uncached
which is why its done!
thats why people dont like emulating MMUs, s/w emulation of MMU,
= very very very slow,
VM is a caching mechanism: RAM space becomes an L1-cache (IYSWIM)
for the virtual space, Hard disk = L2-cache,
virtual space itself doesnt exist hence its "virtual",
VM has to be done by s/w however it is MMU-exception driven,
so its as near to the h/w as you can get namely exceptions,
imagine if the programmer had to do this deliberately in s/w,
>Also when the buffering is local it has much better knowlege of
>the actual buffer usage, so further optimizations are possible
>that would not be at lower level.
I totally disagree, buffers should be dynamically allocated at the
lowest level, preferably not by the programmer, in fact maybe even not
by the filesystem but by a lower level still, though integrating the
filesystem with the lowest level maybe is the best approach,
just as memory caching is done transparently by a very low level of
the CPU, exactly the same applies to everything,
imagine if programmers had to do RAM caching themselves,
Also choice of caching algorithm can make a huge difference this is part of
why I dont want it done by the programmer,
if its not done by the programmer then it can be retargetted ie reimplemented,
caches arent everything, filesystem design is equally important at
determining speed,
a well designed system would be really fast even if the programmer
doesnt do any buffering,
the subroutine call overhead of fputc( fgetc(infp) , outfp) should be
quite tiny because this is such a tiny loop it should entirely be in the
memory cache,
(with fgetc() copying a byte from a low level buffer and fputc() to a low
level buffer)
note that not only will the instructions of this be entirely in the
instruction caches but the file buffer arrays will also be entirely in
data caches, so all round very fast,
I think AmigaOS filesystem is much more efficient than that of Windows XP,
its a good filesystem, but it could be a lot better,
>Your snoop program probably only tells you if something calls dos.library
>thru vectors. It doesn't detect dos.library calling itself directly
>via bsr or jsr.
very bad design if it bypasses the jump vectors, what happens if someone
retargets the jump vectors?
inconsistent behaviour thats what,
someone tried to save a few clock cycles instead of
bsr x
....
x: jmp y
they've done
bsr y
ie ruined the retargettable design to save 1 asm instruction,
you should never trash clean design just to save 1 asm instruction,
the above stops someone fixing some bug in x:
>Also it misses direct DosPacket I/O to filehandler (for example ixemul uses it).
as you point out if it bypasses the jump vector my prog wont see it,
however if the snoop prog sees something though its for real,
If you run my program trackdisk.c you will see that the OS in fact
does sensible buffering: you get a sequence of dots rapidly drawn
followed by a wait, followed by the next sequence,
so the OS is sensibly not writing to the hardware till the cylinder or track
is full,
I think one difference between my perspective and yours is I am an empiricist,
I look at what happens when a system is used or run,
whereas you are following the deductive path where you look at how its
implemented and work from there,
both paths have their own value and both have limitations,
I do use deduction but not on specifics but based on
past observations and experience,
so eg I know that mfm.device i/o is using sensible buffering
just by watching my program output,
also if copying a partition takes much much longer than formatting it
then I know that the filesystem is to blame, I dont even need to
know what filesystem it is,
Here is an example of bad design:
with Memacs if I look at a 5 meg file, it takes 10 years to load,
the silly program appears to be loading the entire file into ram,
with sensible design it should just load the visible part of the
file almost instantly,
another example:
if someone binmails me a 1 meg file attachment,
YAM takes a zillion years to load it,
this means either the email datastructure is badly designed
or YAM is badly designed,
a well designed email structure with 2 large attached files would have say bytes:
#define SENDER -1
#define MESSAGE -2
#define ATTACHMENT -3
SENDER int_sizeof(next_string) "xyz@uvw.com"
MESSAGE int_sizeof( next_string)"hello,\nbye\nxyz"
ATTACHMENT NAME int_sizeof( name ) "story" int_sizeof(file)
"A long story: once upon a time, last week, "
......
[approx 1 meg here]
......
"and lived happily ever after"
ATTACHMENT NAME int_sizeof( next_string ) "another_story" int_sizeof(file)
"Another long story: once upon a time, last week, "
......
[approx 1 meg here]
......
"and they also lived happily ever after"
then YAM only needs to load SENDER + MESSAGE, but ATTACHMENT it reads in
the name then skips the contents to the next attachment reads name
etc printing out:
sender: xyz@uvw
message:
hello,
bye
xyz
attachment: story 1meg
attachment: another_story 1 meg
this should happen quite fast, if it doesnt then there
must be something wrong with the filesystem, a well designed filesystem
should allow you to random access any part quite quickly,
so eg the file must *not* be solely a linked list of blocks
but be say an initial block giving the positions of
the data blocks, if the first block isnt large enough
then the tree needs more levels, so always the first block
should span the entire file,
this way it will take log_blocksize( filesize ) to random
access the file. So if blocksize is 512 ints then
its log_512( filesize ) reads, ie
2 reads to locate from 262144 byte file,
3 reads from 134000000 byte file,
ie approx 3 reads to get to any position of a 130 meg file,
anyway YAM should load a big binmail real fast,
it doesnt, it can take several minutes on my A1200,
something somewhere is wrongly designed:
either YAM or email-datastructures or the filesystem,
I dont know which,
-
@whoosh777
So anyway, how's the big-endian memory emulation idea progressing? Somewhere in the chip / trackdisk / aros install posts I lost where you were up to.
Are you still planning to attempt it?
-
@bloodline
/*
TCP/IP stacks are hard, but Wez is working on one.
Did you not use Datatypes on your Amiga?
*/
no, I've not gone too deeply into graphics as I find it too
open ended and arbitrary, though its very satisfying to look at,
same reason I didnt become an artist,
so when I have needed graphics I've coded it directly eg
iffparse.library for iff files,
or used 3rd party code for a specific picture file,
/*
You seem hung up on SCSI. SCSI is a very old idea. Hard drives and
CD/DVD drives all go on the IDE bus, all other devices go on the
USB or the Firewire bus.
AROS can use CD/DVD drives, because AROS has an ide.device.
SCSI is dead, no normal computer equipment use it
*/
I bought a USB external drive today so I see what you mean:
£40 for 120 Gig, £60 for the case though, probably 10 x the capacity of
an external SCSI for that price,
I think USB outdoes SCSI, but SCSI has advantages (not price) over IDE:
with IDE my machine only has 2 slots,
for me personally I have complete docs for coding cross platform SCSI,
but maybe I can learn to code USB,
/*
The thing I hate most about all GUI's is "auto rise",
that is when you single click on a window and it is brought to the
front of the display. I hate it. AROS does not do this, and I like it that way
*/
I agree entirely,
single click should activate and double click "rise",
and I think its not just subjective but "auto rise" is a deficient concept
in that its impossible to "activate" without "rise"
Question: can you outline what is involved in communicating with a
hardware device on the PC?
(thinking about AROS drivers)
explain it in general terms understandable to someone only familiar with
the classic 68k Amiga,
how do you communicate with a generic PC h/w unit?
alternatively select a specific h/w unit and explain how this
is controlled directly in assembler,
eg are there specific absolute memory addresses for say PCI socket 1,
and is there some kind of structuring to the reads + writes,
eg for a write might it be:
write data length to $12340
write pointer to data to $12344
set bit 1 of $12348 to begin the write,
interrupt 123 happens on write completion,
and eg the data itself will be structured in a way
private to that specific device,
I can see that all PCs have the same structure:
some PCI sockets, AGP socket(s), SIMM sockets, maybe IDE socket(s),
maybe USB sockets,
and then a lot of h/w is via these sockets,
you mentioned IDE bus and USB bus, presumably the bus amounts to
an initial socket??
so I presume each socket has an assembler level API,
-
/*
TCP/IP stacks are hard, but Wez is working on one.
Did you not use Datatypes on your Amiga?
*/
no, I've not gone too deeply into graphics as I find it too
open ended and arbitrary, though its very satisfying to look at,
same reason I didnt become an artist,
so when I have needed graphics I've coded it directly eg
iffparse.library for iff files,
or used 3rd party code for a specific picture file,
From now on, you will use Datatypes if you need to support any file type. :-D
/*
You seem hung up on SCSI. SCSI is a very old idea. Hard drives and
CD/DVD drives all go on the IDE bus, all other devices go on the
USB or the Firewire bus.
AROS can use CD/DVD drives, because AROS has an ide.device.
SCSI is dead, no normal computer equipment use it
*/
I bought a USB external drive today so I see what you mean:
£40 for 120 Gig, £60 for the case though, probably 10 x the capacity of
an external SCSI for that price,
I think USB outdoes SCSI, but SCSI has advantages (not price) over IDE:
with IDE my machine only has 2 slots,
for me personally I have complete docs for coding cross platform SCSI,
but maybe I can learn to code USB,
If you have 2 IDE slots then you can use 4 devices.
That's right each IDE slot can support 2 devices, it you buy an IDE cable it has three plugs on it, one for the Motherboard and one for each of the devices the slot can support. If you do put more than one device on a single IDE slow, one device must be set to Master, the other must be set to Slave. This is doen using some jumpers at the back of the device.
Learn to use the USB, it is much better than SCSI.
Question: can you outline what is involved in communicating with a
hardware device on the PC?
(thinking about AROS drivers)
explain it in general terms understandable to someone only familiar with
the classic 68k Amiga,
how do you communicate with a generic PC h/w unit?
alternatively select a specific h/w unit and explain how this
is controlled directly in assembler,
eg are there specific absolute memory addresses for say PCI socket 1,
and is there some kind of structuring to the reads + writes,
eg for a write might it be:
write data length to $12340
write pointer to data to $12344
set bit 1 of $12348 to begin the write,
interrupt 123 happens on write completion,
and eg the data itself will be structured in a way
private to that specific device,
I can see that all PCs have the same structure:
some PCI sockets, AGP socket(s), SIMM sockets, maybe IDE socket(s),
maybe USB sockets,
and then a lot of h/w is via these sockets,
you mentioned IDE bus and USB bus, presumably the bus amounts to
an initial socket??
so I presume each socket has an assembler level API,
Ok... firstly we don't use any ASM in the drivers, since you will find the same network card/graphics card/sound card whatever, in an x86 machine, a PPC machine or whatever etc... so that driver should be portable across the CPU types.
You do not program the PCI slots yourself. As a driver you request infomation about the attached hardware from the PCI drivers (which I think is the pci.library in AROS). You use the PCI drivers for all access to devices on the PCI bus, and since almost everything in the computer is attached via that bus, this is the thing you need to learn about. Everything hangs off the PCI, this is the bridge between the CPU and the hardware. The PCI drivers will provide you with any information you need about the attached hardware.
I'm not sure how good the AROS PCI driver docs are, but it's a pretty standard implementation.
-
@whoosh777
I havent used the blitter for a long time but what happens if you give the blitter an odd address, do you get an exception or just a horrible crash??
No exception. The lowest bit of the address is ignored, so you would get odd_address - 1.
as I said I can turn all the criticisms of my code around into criticisms of the system design, both h/w and OS,
I am sure of that. However, I would still recommend just testing against NULL return as documented.
Even if the app crashes, there is no way to "remove task" safely, since there is no resource tracking or separated address spaces.
if you had just memory tracking then you could remove the tasks allocated memory + code + stack,
I'm afraid that won't work. The memory allocated by the task can still be in use by other tasks / processes. Also the program seglist could be used by interrupts, hooks or other processes. This is why you can't free the task memory or unload the seglist.
With such methods all buffering would be left at the lower level (filesystem and device driver), thru several APIs.
... Lots of stuff comparing RAM L1/L2 cache and medium cache ...
correction: closer buffering is to the h/w the faster it is,
see CPU caches for example
I'm afraid this comparision is totally unfair, as typically the medium is tens to hundreds times slower than memory, not to mention L1/L2. It certainly makes no sense at all to locally cache memory!
Also when the buffering is local it has much better knowlege of the actual buffer usage, so further optimizations are possible that would not be at lower level.
I totally disagree, buffers should be dynamically allocated at the lowest level, preferably not by the programmer, in fact maybe even not by the filesystem but by a lower level still, though integrating the filesystem with the lowest level maybe is the best approach
I totally disagree with you, see below for an example.
Also choice of caching algorithm can make a huge difference this is part of why I dont want it done by the programmer,
if its not done by the programmer then it can be retargetted ie reimplemented
But the programmer does not need to do it, libc does it for him/her.
caches arent everything, filesystem design is equally important at determining speed, a well designed system would be really fast even if the programmer doesnt do any buffering, the subroutine call overhead of fputc( fgetc(infp) , outfp) should be quite tiny because this is such a tiny loop it should entirely be in the memory cache, (with fgetc() copying a byte from a low level buffer and fputc() to a low level buffer) note that not only will the instructions of this be entirely in the instruction caches but the file buffer arrays will also be entirely in data caches, so all round very fast,
I think AmigaOS filesystem is much more efficient than that of Windows XP, its a good filesystem, but it could be a lot better,
Well, apparently you don't know how complex the two APIs are, and how much overhead is caused by it. Maybe a simple example will clear it for you.
Lets imagine simple fputc without any buffering, except at the exec device driver level (which you say will be the most efficient):
- fputc calls Write(fh, &ch, 1); to write the char
- Write calls DoPkt with ACTION_WRITE
- DoPkt sets up a DosPacket with ACTION_WRITE and parameters for the write
- DoPkt PutMsg the DosPacket to filesystem MsgPort and Wait for the reply
- filesystem wakes up from Wait() and GetMsg() the DosPacket
- filesystem determines the DosPacket is ACTION_WRITE and process it
- filesystem ACTION_WRITE updates the current block of the file
- filesystem ACTION_WRITE use DoIO CMD_WRITE (or CMD_WRITE64, or HD_SCSICMD etc) to send IORequest to exec device driver
- DoIO use device driver DEV_BEGINIO vector to send the IORequest
- The device driver DEV_BEGINIO link the IORequest to device task for processing, and return
- DoIO WaitIO is waiting for the IO to finish
- The device task will process the IORequest, see that it's CMD_WRITE (or whatever), and update buffers (and perhaps do the actual IO).
- When the IO is finished the IORequest will return (ReplyMsg)
- DoIO's WaitIO call wakes up, and DoIO returns
- filesystem checks for IO error and io_Actual to see write was successful
- filesystem ACTION_WRITE set dp_Ret1 to 1 (written 1 byte) and dp_Ret2 to 0 and PutMsg() the DosPacket back to caller (DoPkt)
- DoPkt's Wait wakes up, and DoPkt GetMsg the reply DosPacket, and moves dp_Ret1 to d0, and dp_Ret2 to pr_Result2 (IoErr) and returns
- Write returns with 1 byte written
- fputc returns with 1 byte written
The above sequence is for writing single byte without local buffering. It involves several task switches (scheduling) and waiting. In all it is very very time consuming and will kill the performance, regardless of caches.
Now, if you put the caching to filesystem the sequence gets a lot shorter:
- fputc calls Write(fh, &ch, 1); to write the char
- Write calls DoPkt with ACTION_WRITE
- DoPkt sets up a DosPacket with ACTION_WRITE and parameters for the write
- DoPkt PutMsg the DosPacket to filesystem MsgPort and Wait for the reply
- filesystem wakes up from Wait() and GetMsg() the DosPacket
- filesystem determines the DosPacket is ACTION_WRITE and process it
- filesystem ACTION_WRITE updates the current block of the file in cache
- filesystem ACTION_WRITE set dp_Ret1 to 1 (written 1 byte) and dp_Ret2 to 0 and PutMsg() the DosPacket back to caller
- DoPkt's Wait wakes up, and DoPkt GetMsg the reply DosPacket, and moves dp_Ret1 to d0, and dp_Ret2 to pr_Result2 (IoErr) and returns
- Write returns with 1 byte written
- fputc returns with 1 byte written
It still involves several task switches (scheduling) and waiting.
Now, lets put the cache to fputc:
- fputc puts the char to local buffer
- fputc return with 1 byte written
No task switching is involved. Depending on the buffering mode, only filling up the buffer or linefeed will cause actually flush of the cache (Write).
If you still fail to see my point, I can't really help it.
so the OS is sensibly not writing to the hardware till the cylinder or track is full
Only because you write full tracks. If you would do small writes, it would rewrite the same track several times.
-
Karlos wrote:
@whoosh777
So anyway, how's the big-endian memory emulation idea progressing? Somewhere in the chip / trackdisk / aros install posts I lost where you were up to.
Are you still planning to attempt it?
I never said I would attempt it, though its a
possibility, I'm ruling nothing in ruling nothing out
IYSWIM,
at the moment my time is being taken up sorting out
the h/w of my system,
I bought a KVM switch: 2 PCs to share monitor+keybd +mouse,
took maybe 2 hours to figure out the cabling as I have
lots of cables but not all the right ones,
today I bought the right cables + converters but
some were not in stock, then I found that my
PC cannot use the mouse if there are too many
extensions: the A1200 has no problem whatsoever,
the PC cannot cope,
I may have to buy a USB mouse, I want the PC to join
the A1200 in another room with lengths of cables
connecting them to the room I program in, I do this
to have total silence.
I also bought an external USB drive: £40 for 120Gig
and £60 for the case (I think), (see earlier posting
for the correct price),
I want to see if I can externalise the IDE drive,
then I will boot up in different environments,
once the h/w is reasonably set up then I will
look further into AROS. I havent figured out how
I will transfer data to and from AROS,
I wonder if its possible to impose AmigaDOS onto
the PC floppies, ie treat them as small hard disks,
then I could transfer data to and
from the A1200,
if UAE is integrated successfully into little endian
AROS then I may not bother with a big endian AROS,
its completely a practical matter,
anyway the very first program I will write is
"hello world",
#include
int main( int argc, char **argv )
{
printf("hello world\n");
return( 0 ) ;
}
I'm dreading what flaw Piru will find, I cant see any
but he will find something, maybe it should be
char *argv[]?? or should I check for an error from
printf eg a shell may not be open,
the difficulty with "hello world" being setting up the compiler,
after that I will try some small but useful programs
little utilities I've written out of necessity,
dabbling with AROS itself is much further down
the line,
I like to move gradually, if you recall at the
start of the thread I hadnt got a PC and
wasnt ready to look at the AROS sites, but now
I've got the PC + visited the sites and installed
+ tried out AROS,
BTW I hope AROS dont reimplement OS4 as that would be
in bad taste I think. The open nature of AROS makes
it eternal in some sense, so I think like Linux and
GNU it will gradually succeed, if you visit www.gnu.org
(or is it ftp.gnu.org) its worth reading the interview
there with Richard Stallman on how
GNU begun, I think he started it with GNU emacs,
so it begun with just GNU emacs, I dont know if
thats a reimplemenation of a Unix emacs,
or if it was a brand new program,
the selling point of AmigaOS is its so direct,
both for users and developers, its so straightforward
to write programs, also it generally doesnt
pretend to be bigger than it is,
no gratuitous bloat to make it look like several Gig,
my A1200 has a 1/2 meg ROM, I know this by watching
a memory meter and running CPU fastrom,
you can run an A1200 in 2 Meg so the diskloaded libraries
must be under 2 meg, thus it fits in 2.5 Meg, probably
quite a bit less,
IMO the extra functionality that Windows XP has
cannot be more than a few Meg, so I can easily
believe XP to be say less than 5 Meg,
a really interesting project will be to "measure" XP,
1 Meg of OS is a huge amount of stuff, so I think
MS bloated up their OS with 100's of megs of non
OS material masquerading as OS,
IMO also Windows XP looks like the work of a few
dozen developers at most, it has that feel,
maybe 10 developers writing the programs and
15 wrting the OS,
so if AROS has 11 developers I think they're doing well,
wasnt Linux done mainly by 1 developer initially??
of course they will hype it up
as man centuries of work, but note that
25 developers working for 4 years == 1 man century,
anyway for me getting involved with AROS itself
is quite a bit later on, first I want to try out
some programs that use the current API rather than
work on the API itself. What is really interesting
is that if you locate OS bugs you can actually fix
them yourself!
no more workarounds of OS bugs,
-
bloodline wrote:
/*
TCP/IP stacks are hard, but Wez is working on one.
Did you not use Datatypes on your Amiga?
*/
no, I've not gone too deeply into graphics as I find it too
open ended and arbitrary, though its very satisfying to look at,
same reason I didnt become an artist,
so when I have needed graphics I've coded it directly eg
iffparse.library for iff files,
or used 3rd party code for a specific picture file,
From now on, you will use Datatypes if you need to support any file type. :-D
maybe I will attempt a test Datatypes program
once I have gcc set up, I'm spending so much
money right now on h/w getting this machine set up,
BTW HP say I can only make 1 set of system recovery CDs
which I did today, and they seem to be saying its only
usable on this system,
the blurb said I got "MS Windows XP Home Edition",
but I got no CD, so its not really Windows XP if I
cannot use it on another system: what happens if I
replace the motherboard + CPU to a clone??
/*
You seem hung up on SCSI. SCSI is a very old idea. Hard drives and
CD/DVD drives all go on the IDE bus, all other devices go on the
USB or the Firewire bus.
AROS can use CD/DVD drives, because AROS has an ide.device.
SCSI is dead, no normal computer equipment use it
*/
I bought a USB external drive today so I see what you mean:
£40 for 120 Gig, £60 for the case though, probably 10 x the capacity of
an external SCSI for that price,
I think USB outdoes SCSI, but SCSI has advantages (not price) over IDE:
with IDE my machine only has 2 slots,
for me personally I have complete docs for coding cross platform SCSI,
but maybe I can learn to code USB,
If you have 2 IDE slots then you can use 4 devices.
That's right each IDE slot can support 2 devices, it you buy an IDE cable it has three plugs on it, one for the Motherboard and one for each of the devices the slot can support. If you do put more than one device on a single IDE slow, one device must be set to Master, the other must be set to Slave. This is doen using some jumpers at the back of the device.
4 is probably more than enough,
is it possible to externalize the drive??
Learn to use the USB, it is much better than SCSI.
I hope I can get hold of well written USB API docs,
Question: can you outline what is involved in communicating with a
hardware device on the PC?
(thinking about AROS drivers)
explain it in general terms understandable to someone only familiar with
the classic 68k Amiga,
how do you communicate with a generic PC h/w unit?
alternatively select a specific h/w unit and explain how this
is controlled directly in assembler,
eg are there specific absolute memory addresses for say PCI socket 1,
and is there some kind of structuring to the reads + writes,
eg for a write might it be:
write data length to $12340
write pointer to data to $12344
set bit 1 of $12348 to begin the write,
interrupt 123 happens on write completion,
and eg the data itself will be structured in a way
private to that specific device,
I can see that all PCs have the same structure:
some PCI sockets, AGP socket(s), SIMM sockets, maybe IDE socket(s),
maybe USB sockets,
and then a lot of h/w is via these sockets,
you mentioned IDE bus and USB bus, presumably the bus amounts to
an initial socket??
so I presume each socket has an assembler level API,
Ok... firstly we don't use any ASM in the drivers, since you will find the same network card/graphics card/sound card whatever, in an x86 machine, a PPC machine or whatever etc... so that driver should be portable across the CPU types.
I wondered whether h/w interfaces being at such a low level whether one is forced to use ASM,
You do not program the PCI slots yourself. As a driver you request infomation about the attached hardware from the PCI drivers (which I think is the pci.library in AROS).
ok, so the drivers are above pci.library,
should be very interesting autodocs,
that should make writing a driver much more doable,
can you show a code fragment from a real driver?
You use the PCI drivers for all access to devices on the PCI bus, and since almost everything in the computer is attached via that bus, this is the thing you need to learn about.
can you explain what you mean by a bus?
is it comparable to the data and address buses
connecting a CPU and RAM??
also is the USB bus comparable to the PCI bus?
does IDE have a bus?
Everything hangs off the PCI, this is the bridge between the CPU and the hardware. The PCI drivers will provide you with any information you need about the attached hardware.
I'm not sure how good the AROS PCI driver docs are, but it's a pretty standard implementation.
maybe if you make a case study of a specific driver
available it will get people interested in
writing drivers, I would certainly study such,
-
@Piru,
I think you know tooo much about AmigaOS!
too much knowledge can be a dangerous thing,
I am thankful I dont have such in depth knowledge,
it would cloud my judgement,
De Bono said that forgetting is an essential part of
intelligence as it acts as a filter,
Piru wrote:
@whoosh777
I havent used the blitter for a long time but what happens if you give the blitter an odd address, do you get an exception or just a horrible crash??
No exception. The lowest bit of the address is ignored, so you would get odd_address - 1.
ok so the blitter is basically quite a maniac!
what happens if you send it off into nonexistent RAM
or into Fastram (which presumably is nonexistent from
its POV),
the last time I looked at the blitter was on my A500,
last century,
Even if the app crashes, there is no way to "remove task" safely, since there is no resource tracking or separated address spaces.
if you had just memory tracking then you could remove the tasks allocated memory + code + stack,
I'm afraid that won't work. The memory allocated by the task can still be in use by other tasks / processes. Also the program seglist could be used by interrupts, hooks or other processes. This is why you can't free the task memory or unload the seglist.
ok I see what you mean, again this is bad system design:
namely not anticipating this type of problem and its
probably going to be difficult to fix this,
My problem is I trust the OS too much,
some OS design criticisms here:
1. shared memory for messaging was a bad decision,
if you do this it should be via some new API call
AllocMessage( struct Task *task, int size ) ;
for sending messages to "task", that way the
message would belong to the recipient managed by the OS,
so you could remove it on removal of the recipient,
the design error was about ownership, AmigaOS made
sender the owner, when in fact it should have been
recipient: if I send you a letter, you own that letter
not me, if I own that letter the world is going to
get really complicated and probably grind to a halt
and give up,
this approach would be better because it would cope
with a task on another machine, ie when you send the
message the OS could copy it if necessary,
2. Code for other tasks to execute which I think is
what you are referring to:
this could have been done by eg
SetupPublicCode( "filename" ) ;
where the OS would load the public code from a file,
exactly same thing for my snoop program:
SetVectorOffset("filename");
The Law of Whoosh:
User progs should be forbidden via API from choosing
public bytes,
(ie user progs cannot delineate public memory areas
to the OS)
This includes: user progs shall *not* set up
struct Message's, OS datastructures shall never
be allocated by user code,
user progs shall not set up
code to be executed by other tasks in no shape way
or form, neither Interrupts, nor jump vectors,
really setting up public interrupts is an OS level
thing so should be disallowed for user programs,
setting up private interrupts is fine,
there need to be 2 types of programs: user programs
and system programs, system programs may set up
public interrupts,
perhaps via a file attribute flag: (like rwed),
or via a "priority" system: each program would have
a priority, only the user via a password may change
program "priority" via Workbench information,
I dont want to enter the minefield of computer security
here, but I know from my understanding of computers that
a completely correct system can be done which will
stand the test of time, ie it will be logically foolproof,
what the OS can do then is when it runs a program
it notes whether its a system program,
if a non system program makes an API call to set
public bytes the task should be suspended and removed,
public datastructures and public code must be entirely
set up by the OS,
You tend to look at things in great depth from
the AmigaOS POV,
however I tend to look at things from the POV of an
abstract generalised OS the way I was taught to by
well qualified theorists,
Its a very safe way to look at things,
Also when the buffering is local it has much better knowlege of the actual buffer usage, so further optimizations are possible that would not be at lower level.
I totally disagree, buffers should be dynamically allocated at the lowest level, preferably not by the programmer, in fact maybe even not by the filesystem but by a lower level still, though integrating the filesystem with the lowest level maybe is the best approach
I totally disagree with you, see below for an example.
all your example proves is how terribly designed
dos.library is,
I didnt realise it was that useless,
so yes your point is correct *relative* to AmigaOS,
I was talking relative to a "sane" system,
Also choice of caching algorithm can make a huge difference this is part of why I dont want it done by the programmer,
if its not done by the programmer then it can be retargetted ie reimplemented
But the programmer does not need to do it, libc does it for him/her.
given that dos.library is so useless then yes
libc needs to shield out dos.library,
and it may become more efficient but never really
efficient,
I am learning a lot of things from you,
but things I would prefer not to know,
caches arent everything, filesystem design is equally important at determining speed, a well designed system would be really fast even if the programmer doesnt do any buffering,
read my lips!
(see later),
the subroutine call overhead of fputc( fgetc(infp) , outfp) should be quite tiny because this is such a tiny loop it should entirely be in the memory cache, (with fgetc() copying a byte from a low level buffer and fputc() to a low level buffer) note that not only will the instructions of this be entirely in the instruction caches but the file buffer arrays will also be entirely in data caches, so all round very fast,
I think AmigaOS filesystem is much more efficient than that of Windows XP, its a good filesystem, but it could be a lot better,
Well, apparently you don't know how complex the two APIs are, and how much overhead is caused by it.
correct: and I'm quite shocked by your example,
correction: you need to replace the words "how complex" by
"what an incomprehensible mess",
did someone sabotage dos.library,
I'm beginning to wonder,
Maybe a simple example will clear it for you.
it did, unfortunately,
Lets imagine simple fputc without any buffering, except at the exec device driver level (which you say will be the most efficient):
- fputc calls Write(fh, &ch, 1); to write the char
- Write calls DoPkt with ACTION_WRITE
- DoPkt sets up a DosPacket with ACTION_WRITE and parameters for the write
- DoPkt PutMsg the DosPacket to filesystem MsgPort and Wait for the reply
- filesystem wakes up from Wait() and GetMsg() the DosPacket
- filesystem determines the DosPacket is ACTION_WRITE and process it
- filesystem ACTION_WRITE updates the current block of the file
- filesystem ACTION_WRITE use DoIO CMD_WRITE (or CMD_WRITE64, or HD_SCSICMD etc) to send IORequest to exec device driver
- DoIO use device driver DEV_BEGINIO vector to send the IORequest
- The device driver DEV_BEGINIO link the IORequest to device task for processing, and return
- DoIO WaitIO is waiting for the IO to finish
- The device task will process the IORequest, see that it's CMD_WRITE (or whatever), and update buffers (and perhaps do the actual IO).
- When the IO is finished the IORequest will return (ReplyMsg)
- DoIO's WaitIO call wakes up, and DoIO returns
- filesystem checks for IO error and io_Actual to see write was successful
- filesystem ACTION_WRITE set dp_Ret1 to 1 (written 1 byte) and dp_Ret2 to 0 and PutMsg() the DosPacket back to caller (DoPkt)
- DoPkt's Wait wakes up, and DoPkt GetMsg the reply DosPacket, and moves dp_Ret1 to d0, and dp_Ret2 to pr_Result2 (IoErr) and returns
- Write returns with 1 byte written
- fputc returns with 1 byte written
I'm totally horrified,
The above sequence is for writing single byte without local buffering. It involves several task switches (scheduling) and waiting. In all it is very very time consuming and will kill the performance, regardless of caches.
one of the nice things about a lot of AmigaOS is it
doesnt bother with OS tasks, OS API calls are
executed by the task,
not so with dos.library,
IMO the OS being executed by the task is one of the
redeeming features of AmigaOS, your example proves
how useless the concept of separate OS tasks is,
I now understand why AmigaOS is often so responsive,
and why the filesystem can be so unresponsive,
Access to a particular partition should be controlled
via eg semaphores, so only 1 exclusive task should
write to a partition, but many may read a partition,
before a task may write to a partition, it should be
queued up till all current readers have finished and gone,
all this partition access happening via OS library code,
ie not via user code,
Indisputible Fact: only 1 task may write to a partition at a time, many may read simultaneously, (**)
dos.library appears (maybe you'll correct me as you
have memorised AmigaOS) to achieve (**) by
having filesystem tasks,
Now maybe because disks are heavy duty things
you should also make read access exclusive,
otherwise the disk head will keep flitting between
2 positions and take forever, I have to think about
this further,
to keep the design simple it may be best to make
all access to a given physical drive exclusive,
regardless of filesystem, (1)
note how Semaphores achieve exactly the same
goal as filesystem-tasks,
I have to tell you that filesystem-tasks sounds
very Unixish,
IMO (1) is the best approach via Semaphores,
probably I wouldnt use exec's Semaphores but
implement my own ones specifically for the
filesystem(s): general purpose semaphores
are going to be much slower than special
purpose ones,
via the above explanation I can use
exclusion only Semaphores which can be done
very efficiently via eg #?.library code:
TAS (SEMAPHORE_OFFSET,A2) ; fp in non scratch a2,
BEQ continue
; queue up our task and surrender the cpu,
; time overhead here, atypical situation: rare to queue up,
continue: ; we own the semaphore,
; do the i/o eg fputc,
so the semaphore amounts to 2 asm instructions
when there's no queue, using exec would be too
much overhead for fputc,
I think BSET can also be used instead of TAS,
not had time to see which is better,
semaphores require indivisible read-modify-write
asm instructions,
BTW I think you raise some very interesting points,
so maybe your highly specific knowledge has some value!
Now, if you put the caching to filesystem the sequence gets a lot shorter:
- fputc calls Write(fh, &ch, 1); to write the char
- Write calls DoPkt with ACTION_WRITE
- DoPkt sets up a DosPacket with ACTION_WRITE and parameters for the write
- DoPkt PutMsg the DosPacket to filesystem MsgPort and Wait for the reply
- filesystem wakes up from Wait() and GetMsg() the DosPacket
- filesystem determines the DosPacket is ACTION_WRITE and process it
- filesystem ACTION_WRITE updates the current block of the file in cache
- filesystem ACTION_WRITE set dp_Ret1 to 1 (written 1 byte) and dp_Ret2 to 0 and PutMsg() the DosPacket back to caller
- DoPkt's Wait wakes up, and DoPkt GetMsg the reply DosPacket, and moves dp_Ret1 to d0, and dp_Ret2 to pr_Result2 (IoErr) and returns
- Write returns with 1 byte written
- fputc returns with 1 byte written
It still involves several task switches (scheduling) and waiting.
basically the design flaw is filesystem tasks,
the OS is just datastructures + code to manage
those datastructures, I think its fine if said code is
executed by user tasks, the code itself would be
library code, why have the silly extra task switch +
messaging overhead of having a filesystem execute
exactly the same code??
Now, lets put the cache to fputc:
- fputc puts the char to local buffer
- fputc return with 1 byte written
No task switching is involved. Depending on the buffering mode, only filling up the buffer or linefeed will cause actually flush of the cache (Write).
If you still fail to see my point, I can't really help it.
Not only do I see your point, I also see the cause
of your point and beyond that cause to the fix of the
cause of your point,
your last code fragment underlines my comment that
filesystems should be executed in the calling tasks
context,
note also my comments that there should be
exclusive read + write access at the physical drive level,
its fine to have 5 tasks in parallel accessing 5
different physical drives,
the idea may need some refinements eg you may need
to have exclusive access to all drives of
a given SCSI interface socket,
its all about whether (parallel action) faster than
(serial action),
only verifiable by experiment, = empiricism,
I know that parallel access to a given drive
is really inefficient,
there are 2 totally different issues going on here:
1. datastructure complexity: 5 tasks in parallel
modifying the same datastructures could be too complex,
so you use Semaphores to reduce this to 1 task,
dont use Forbid() Permit() as its a local exclusion
problem, like a local anaesthetic, just
anaesthetize the physical drive, not the entire computer,
2. data transfer speed: if 2 tasks in parallel
access the same drive, with 3cm between the disk head
position, an unacceptable amount of time will be
spent by the head moving between the 2 positions,
Note that the speed issue probably is less relevant
for Ram:, though caching issues will affect speed,
so it may be best not to flit around ram: too much,
IMO you only need 2 levels of caches:
cache for indivisible physical disk reads,
call these cylinders (or maybe tracks),
cache for files, the file write cache probably should be
the size of the largest available free subset of
available indivisible disk reads,
the file read cache will be quite different from
the write cache, may even have a collective file
read cache,
fgetc and fputc would deal almost directly with
this file cache, which is kind of what I was
thinking about in my original comment,
[removed a comment which I realised was false]
Semaphoring adds an overhead of 2 asm instructions
in the typical case (just one user prog, no queues),
once the file write cache is full you read the foreseen
cylinder, write out the cache to the buffer,
write modified buffer to the drive,
the new largest available size will now be smaller
(unless eg file deletions have occured) so the
same buffer could be retained for this file,
If the program flushes the buffer early eg
by closing the file then a different cylinder
may be chosen for the write eg the nearest
cylinder with enough space to reduce disk head
movement,
also for file reads the file cache may only
need to be partially filled, just fill in
the blocks in the current disk read,
no need to fill the whole thing,
possibly achieved via collective read cache,
so if the prog looks at position 100000 of the
file, then say this is in block 200 of the file
and block 200 is in cylinder 10 of the disk,
then cylinder 10 = indivisible disk read (maybe track),
is read to fill in an indivisible disk read cache,
(A)
(read caches are quite different from write caches),
I wont copy other blocks of this file until and unless
requested by the program,
If the program now moves to a totally different
file position in a totally different cylinder,
the cache (A) would still be kept, eg I may keep
allocating such caches according to some policy,
now if the prog references a different subblock of
(A), I copy that over into the file cache,
no disk read required,
I dont just have caches I have caches of caches,
when the collective file read cache is full I will override particular subblocks by new read blocks,
according to a well thought through policy,
anyway I am illustrating here that caching is quite
complex and must not be done by the user program,
user program caches just add an extra array copy
overhead, you are just replacing a function call overhead
with an array copy overhead + index management overhead:
fputc( c , fp ) ;
vs
mybuffer[ i++ ] = c ; /* index management */
/*
unnecessary memory access and index update + address
calculation
*/
if( i==full ) /* index caution */
{
fput_array( mybuffer , full , fp ) ;
i = 0 ; /* index reset */
}
fput_array() has to do memory to memory copying,
via indexing => duplication of indexing effort,
if(i==full) effort also duplicated,
my method: c only gets written to the file cache once,
your method: c is written to memory twice,
read from memory once, 3 x as many memory accesses
your method: indexing happens twice,
my method: indexing happens once,
your method: checking for index full happens twice,
my method: happens once,
in assembler my method could be merely:
move.l c,d0
jsr fputc
if fp is in a nonscratch register argument,
(an argument in favour of nonscratch argument registers )
and an extra 2 asm instructions of overhead for
the semaphoring in OS library function fputc,
1 semaphore per physical drive, pointer to semaphore
is a field in fp,
note that in your method the user progs buffering
is quite a number of instructions which are
themselves memory accesses,
those instruction fetches are probably cached, but
everything here is probably cached,
:instructions, buffers, stack, all in CPU caches,
so the OS is sensibly not writing to the hardware till the cylinder or track is full
Only because you write full tracks. If you would do small writes, it would rewrite the same track several times.
[/quote]
for writes my approach would use several track caches,
ie caching of the caches:
eg on a current Intel I may buffer the entire
floppy disk,
if its a 120Gig disk and 200 Mb free Ram I may
dynamically go up to 100Mb of caches,
for the floppy disk write example on Intel sectors referenced would be read,
writing would happen at CloseDevice() time
and only of modified tracks,
so a total minimum of track writes would happen,
There may be some glitches in what I've said
(its late at night)
but the underlying idea is rock solid,
-
I think in the above post I may have missed out
1 level of indirection with the semaphore,
I often do the wrong amount of indirection
with 68k asm,
so the correct version may be:
TAS ([OFFSET_SEMAPHORE,a2],0)
BEQ continue
....; queue up for exclusive access,
continue:
....
(the queueing up itself could be done via
exec semaphores,
but no queue => no exec semaphores => fast,
)
Well IMO Windows XP filesystem on IDE as seen through WinUAE is considerably slower than FFS on my A1200
via Blizzard SCSI-2,
doing something as trivial as
assign something: somedirectory add
or
echo "hello" >xyz:uvw
takes possibly even 1 minute!
I found I can run my datesorter program on
the whole of Windows XP's filesystem by selecting
"Add PC drives at startup" in WinUAE,
I wanted to see what XP had been up to,
what I observed is there are huge pauses,
sometimes the directory scan will be quite
rapid,
it may be the layering of dos.library above Windows
filesystem though,
so although I've criticised dos.library it may be
quite good compared to the competition,
I bought an ATI-Radeon 9800 SE for £129 today,
not fitted it yet as too many other setup things
to do first,
I found out you *can* have an external IDE drive:
the USB drive I bought is such:
you put the IDE drive in a case with its own
power supply and a USB-2 cable connects it to
the computer,
also I saw for sale USB2 to PS/2 mouse + keyboard
converters,
My A1200 produces much more powerful video output
than this PC,
the A1200 is also much more robust for keyboard and
mouse extensions:
my A1200 can cope with huge extension cables
for keyboard + mouse + monitor eg 5m,
the PC can only cope with one 1.8 m extender,
if I put 2 the mouse + keyboard stop functioning,
connecting PC + A1200 to my KVM switch and entirely using
Belkin VGA cables my A1200 produces a perfect screen
whereas the PC produces a double image ghost,
so you cant blame the cabling as its identical,
I blame the feeble PC signals which make the ghost
visible via low signal-to-noise ratio (using analogy
of cassettes and dolby),
I've also located examples of unsophisticatedness in Windows XP's windowing:
example: if I open the directory folders window,
and select some file and select "move this file"
a small window appears for me to select
destination directory,
thing is it seizes control of the user interface,
eg I cannot bring the original window to front,
the small file flashes if I try,
I would be in big trouble if Piru found out
that I wrote a program that seized control of the WB,
I cannot even attempt to rename or move another
file,
on AmigaOS the windowing is fully asynchronous,
1 window cannot seize the environment,
(in OS1.2 the WB was much less asynchronous)
note regarding my comments about exclusive access
to drives, that is only for the rename() api call,
not for the GUI rename where you can still edit the
rename, ie only when you press return should
other tasks be locked out from accessing that
drive, other drives no problem,
so WB is more asynchronous than Windows XP,
ne ne ne-ne ne,
gradually dismantling a few years worth of
PC-better-than-Amiga FUD from the internet,
BTW if I run WinUAE with my original WB disk adf file
in "drive 0" I get AGA WinUAE and it is
indistinguishable from the real thing,
:I actually start thinking I am on my A1200,
:you can even slide down the screens, eg
I ran DeluxeMusic which rendered perfectly,
(imperfect rendering if done via Picasso emulation
eg I cannot access quit from the menu),
I slid down the DeluxeMusic screen, the colours
were slightly different from my A1200 but otherwise
it was correct,
I played Bach Fugue and listened, it was correct
but in higher quality via the PC's AC 97 sound card,
I found the font rendering problem was because
I had selected a variable width font, fixed width
fonts are no problem,
Now IMO if you can slide down the AGA screens it
should be possible to slide down the Picasso screens,
ditto for AROS,
though it may be tricky, dont like those immovable
WB screens,
I went to a lot of PC shops today (even though I shouldnt, surfing the high street!), I saw a 128Mb USB-2 keyring for £29.99,
USB2 is like magic,
now I have a PC when I walk into a PC shop I know what
everything is, I know that those XP screens are merely
a selection of one of the standard backdrops,
those icons are exactly the same as my ones,
when I hear the staff talking I actually know what
they are talking about, the only shop that impresses
me now is Maplins. In PC World when I ask about prices,
I am very tempted to say: "you realise thats a total
rip off!" The staff in a lot of shops actually tell me to try Maplins,
now when I walk into PC shops, its like toys everywhere
for me, and so cheap, and I have total compatibility,
everything in Dixons is now compatible with my system,
this XP machine is the ultimate interface + accelerator
card for my OS3.1 ROM via WinUAE, Windows XP is a great
hardware abstraction layer, it abstracts all hardware in
existence, maybe AmigaOS should be sold as a Windows app??
I've never felt so happy since buying this machine,
its like everything is win-win, every question I ask
the answer is yes, yes you can, yes we do, yes we have,
all the adverts now address me,
I havent forgotten AROS though, IMO there will be
a gradual ongoing transfer of power from WinUAE to AROS,
WinUAE hosted is a vision of what AROS could become,
if you try WinUAE either AGA or in truecolour via
AIAB you will know how fantastic the Amiga on Intel h/w
will be,
the moment AROS gets USB-2 its going to be in such a
strong position,
USB-2 is 480Meg/second (I think),
I found that you can even increase the number of
PCI slots by a PCI card which outputs 2 PCI slots,
so thats what a riser card is,
its like wonderland,
£5 keyboards,
128Mb keyring, whats the world coming to!
-
@Piru
>>so c's standard library can be very efficient, eg if you want to copy an
>>arbitrary size of memory you need a very good reason to not use memcpy(),
>>and it deals correctly with overlapping memory,
>memcpy() does not deal with overlapping copies. memmove() and bcopy() do.
depends on the docs you use:
Lattice 5 docs p F-145:
``Also note that memcpy and movemem are smart enough to handle overlapping
memory blocks correctly.''
..........
``Unlike memcpy, memccpy does not handle overlapping memory blocks.
If you specify overlapping blocks to this function, the results are
unpredictable''
If that is a lie its a very carefully worded and consistent lie,
The Lattice 5 docs in 3 pages explain 9 memory functions:
memccpy, memchr, memcmp, memcpy, memset, movmem, repmem, setmem, swmem,
vs Lattice 6: 1 page per function,
anyway Lattice 650 p343 of C Library reference:
says the exact opposite:
``The memcpy function does not handle overlapping memory blocks. If you
specify overlapping blocks to this function, the results are
unpredictable.''
Note the exact same word usage, the second sentence of 650 being
verbatim cut and paste from Lattice 5,
so it looks like someone cut modified
and pasted from the Lattice 5 docs to create the Lattice 650 docs,
was something lost in the editting eg the letter c?
possibly their implementation does it correctly but they realised that
other implementations dont so for portability they used the word
"unpredictable",
I am a pragmatist, if there is a flaw in what I say it will emerge
when I turn my words into code. So yes you can find some glitches in
what I say, but in the end its not a big deal because I will find
the flaws anyway. eg I found that I mustnt use fputc(fgetc(),fp)
to copy a large subset of a file just by direct observation
that it was taking much longer than it should:
I didnt know it was because there was an entire task-switch overhead
involved, but I knew it was much too slow,
-
I went to a lot of PC shops today (even though I shouldnt, surfing the high street!), I saw a 128Mb USB-2 keyring for £29.99,
USB2 is like magic,
Yes it is, and it's getting old now.
now I have a PC when I walk into a PC shop I know what
everything is, I know that those XP screens are merely
a selection of one of the standard backdrops,
those icons are exactly the same as my ones,
when I hear the staff talking I actually know what
they are talking about, the only shop that impresses
me now is Maplins. In PC World when I ask about prices,
I am very tempted to say: "you realise thats a total
rip off!" The staff in a lot of shops actually tell me to try Maplins,
now when I walk into PC shops, its like toys everywhere
for me, and so cheap, and I have total compatibility,
everything in Dixons is now compatible with my system,
this XP machine is the ultimate interface + accelerator
card for my OS3.1 ROM via WinUAE, Windows XP is a great
hardware abstraction layer, it abstracts all hardware in
existence, maybe AmigaOS should be sold as a Windows app??
I've never felt so happy since buying this machine,
its like everything is win-win, every question I ask
the answer is yes, yes you can, yes we do, yes we have,
That's the problem which most amiga users face. They don't realise that they have gone from the cutting edge of technology to the bottom of the pile.
Technology is moving very quickly... In the 10 years since Commodore's demise the whole world of computing has moved on.
the moment AROS gets USB-2 its going to be in such a
strong position,
Yes AROS needs a USB stack.
USB-2 is 480Meg/second (I think),
Actually its 480Megabits per second which is about 60Meg per second. That's still really fast :-)
I found that you can even increase the number of
PCI slots by a PCI card which outputs 2 PCI slots,
so thats what a riser card is,
its like wonderland,
£5 keyboards,
128Mb keyring, whats the world coming to!
I wish more people here would take that little leap into the moden computing world :-)
-
It is only 480Mb/s burst for USB2 though, meaning that although Firewire says it is only 400Mb/s, Firewires rated speed is sustained, so Firewire is actually quite a bit faster than USB2.
-
@whoosh777
SAS/C (6.x) memcpy doesn't handle overlapping copies, at least. Looks like they decided to follow the standard and not support overlapping copies with memcpy after all.
Anyway, standard states that memcpy is not guaranteed to handle overlapping copies, so even if some implementation did, you cannot rely on this feature or you're writing non-portable code.
-
I think this thread could be closed as 'completed as desired'.
It just took 7 years to get around to doing it.
-
I think this thread could be closed as 'completed as desired'.
It just took 7 years to get around to doing it.
:banana::banana::banana::banana::banana::banana:
-
:banana::banana::banana::banana::banana::banana:
+1 =d
-
eg I found that I mustnt use fputc(fgetc(),fp)
to copy a large subset of a file just by direct observation
that it was taking much longer than it should:
I didnt know it was because there was an entire task-switch overhead
involved, but I knew it was much too slow,
using fopen is never a good idea if you want the copy performance. Then you make it worse with the overhead of making read and write calls for every single character. For best speed use no buffering (Open/Read/Write instead of fopen/fread/fwrite) and then read and write in large chunks that are a power of 2 (32k is a good small number ). When copying between different devices you can use multiple threads or asynchronous reads/writes so both devices are busy all the time. When copying on one device it's better to use a much larger buffer and only either read or write.
But unless you understand why you should do these things then it's just cargo cult programming.
However I had to knock up a one off program that had to split some files up and I used fputc/fgetc because it was quicker to code & the run time was a fraction of how long it took to code. Making compromises is the art of being a commercial programmer.