@cdimauro

Quote:

cdimauro wrote: @CosmosUnivers Quote: CosmosUnivers wrote: @ppcamiga1 ARM, PPC, x86, C, C/C++ : designed by female for female (Yin)... 68k and assembler : designed by true male for true male (Yang)... ppcamiga1 : if you are a fake male, it's YOUR problem ! Why do you want to spread the mediocrity ? Better to learn and evolve to become a male ! So, you're replying to THE parrot/troll of the forum with... this?!? Do you SERIOUSLY believe on what you're written or is it another joke?

I see this as @ComosUnivers attempting to communicate with the parrot/troll using simple syntax and loose grammar that the parrot/troll might understand.

_________________
All the way, with 68k

@agami

Quote:

I see this as @ComosUnivers attempting to communicate with the parrot/troll using simple syntax and loose grammar that the parrot/troll might understand.

That's how I perceived it as well.
Hard to tell on this forum though. There's a little crazy in pretty much all of us here :)

@ppcamiga1

my G5 is alive like my C64...

no sense reply for a no sense post.

Last edited by tlosm on 16-Nov-2023 at 02:51 PM.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@CosmosUnivers

I wonder if "Bjarne Stroustrup", like to be called a female.
Have you actually checked who design this things?

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

@Hypex

Assuming that etch induvial core has their own exception handlers, I guess it possible to do some type of mutex check in the exception hander. But what use is it without knowing what data it belongs to, can exception handler also do cache flush, to resync the cores.

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

@matthey

Quote:

matthey wrote: Most of the AmigaOS was written in C with only a few modules in 68k assembler like FFS. Some assembler was used. Libraries were more likely to use some assembler than be 100% C code.

Actually it was bit more than just 'some' assembler. OS 3.1 kickstart source has 526 .asm files totaling ~6 million characters, and 361 .c files totaling ~3.6 million chars.

There are 98 asm files in graphics library with a total of 728 thousand characters, including code for blitter operations (blitbitmap etc.), sprites, copperlists, fonts and text rendering, region operations, and drawing functions (line draw, circle, flood fill etc.).

DOS has 20 asm files totaling 338 thousand characters, covering such things as date strings, BCPL functions, loadseg, readargs, pattern matching, and the entire TRIPOS kernel (2847 lines of asm code).

Console device has 27 asm files totaling 259 thousand characters, and a single .c file with only 338 lines of code.

The filesystem, utility and keymap libraries are 100% asm code. And of course so is exec library, with 21 asm files totaling 527 thousand characters.

In short, Amiga OS was riddled with asm code. Good luck translating that to ppc!

@bhabbott

Quote:

Actually it was bit more than just 'some' assembler. Good luck translating that to ppc!

Well he could have used AROS but we all know 'a real AmigaOS' can not be based on such a highly portable open source abomination, that was translated to x86 before it got to 68k.

AFAIK there is a PPC version running hosted on Linux but that would be to simple for real Amiga-OS-Fourians.

Last edited by OneTimer1 on 16-Nov-2023 at 09:34 PM.

@OneTimer1

Quote:

Well he could have used AROS but we all know 'a real AmigaOS' can not be based on such a highly portable open source abomination, that was translated to x86 before it got to 68k.

I think it is much worse than that. Didn't the narrative use to be :

"AROS is parasitic competition" and "AROS is probably illegal".

Hypex Quote:

It also looks the recent open sourcing of POWER so people can freely fabricate their own designs hasn't encouraged any new lower cost chips to be produced either.

OpenPOWER is not as open as the name implies.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf Quote:

The Case for a Free, Open ISA While instruction set architectures (ISAs) may be proprietary for historical or business reasons, there is no good technical reason for the lack of free, open ISAs: o It’s not an error of omission. Companies with successful ISAs like ARM, IBM, and Intel have patents on quirks of their ISAs, which prevent others from using them without licenses. Negotiations take 6-24 months and they can cost $1M-$10M, which rules out academia and others with small volumes. An ARM license doesn’t even let you design an ARM core; you just get to use their designs. (Only ~15 big companies have licenses that allow new ARM cores.) Even “OpenPOWER” is an oxymoron; you must pay IBM to use its ISA. While business sound, licenses stifle competition and innovation by stopping many from designing and sharing their ISA-compatible cores.

While I believe the RISC-V ISA has limited performance potential and am not a fan including others like architect Mitch Alsup (88k CPU designer), the open RISC-V ISA is making an impact. I believe it is one of the reasons why OpenPOWER has failed to gain traction and it has practically finished off more open MIPS and (Open)SPARC efforts. ARM is relatively cheap and very easy but there is demand for an open ISA and open hardware which can give a competitive cost advantage among other advantages. For an ARM Cortex-A55 CPU core, the licensing cost is likely to be over $1 million USD and a multiple core design with POP for optimized custom blocks is likely to have royalties of 3+%. The roughly equivalent SiFive U74 core may be available for less than $1 million with Verilog HDL source code allowing for customization and requiring no royalty costs for each chip produced. Less up front cost and a 3+% competitive cost advantage for a similar performing product is pretty good as that can translate into 3+% better profit margins. Consider the RPi based on ARM that everyone thinks is so cheap that actually can be undercut in cost and this using RISC-V for just a few million USD. Other custom blocks are needed for a SoC but SiFive has those available too, albeit with a reduced selection. What they have is more than adequate for Amiga need though.

https://www.sifive.com/boards/hifive-unmatched
https://www.sifive.com/boards/hifive-unmatched-revb
https://www.sifive.com/boards/hifive-pro-p550 (OoO cores, newer PCIe, DDR5 at 7nm so $)

This Mini-ITX board with 4xU74 core SoC is discontinued likely because it cost too much at around $700 while there is not enough of a market for RISC-V yet and the large board with PCIe makes it expensive (there is no good open hardware GPU that could be integrated to reduce the cost). SiFive may leave the market of building boards themselves choosing to stick to higher margin licensing and custom design for customers. It is easier to remove blocks from an SoC as other than so many expensive PCIe lanes for a GPU, an integrated GPU would be more competitive (Trevor would probably prefer the current design and $700 sounds cheap in AmigaNever land). It may be possible to customize the U74 core into a 68k core as it is a similar design to the 68060 core and this should boost performance as the pipeline design can perform an EA calc and ALU operation of an instruction in the same pipeline which is not possible for RISC-V instructions. It could be another option if 68060 licensing and/or royalties were unreasonable. It would require some serious development to execute 68k instructions but the core with modern blocks for a SoC could be more affordable than other options. RISC-V may not have the best support yet but it is already ahead of any scaled down OpenPOWER core and it can scale down further where it is more competitive. The more open ISA and hardware is already an advantage in areas too.

Hypex Quote:

The most sensitive would be Forbid/Permit. Actually more sensitive would be Disable/Enable. And these need to modify a single byte. PPC doesn't like to work with scalars that aren't words. Especially with alignment and Amiga structures are not long aligned. However PPC does include instructions for atomic access. The lwarx and stwcx pair. In typical PPC style it must be loaded, modified, then stored back. This looks like a logical way to perform an atomic lock. Or atomic increment. However it must be accessed as a whole word. Easy enough to long align it and mask it off. But that looks somewhat sloppy and code should be able to directly modify the intended scalar. Of course the 68K had no problem doing a simple atomic add. But I do wonder, if 256 tasks in a row Forbid, then relinquished it temporary with a Wait, that would surely break it. Amusingly enough, there is a Microsoft blog that talks about it. It's fairly recent from 2018, but the original must surely be 2 decades old going by the context, since the only time I recall Microsoft touching PPC was for the short lived WindowsNT PPC port. https://devblogs.microsoft.com/oldnewthing/20180814-00/?p=99485

Yes, the way the 68k AmigaOS disables interrupts is tied to the 68k. It is not unusual to use the Forbid/Permit and Enable/Disable 68k assembler macros which are still used in even the newest 68k AmigaOS.

Yes. PPC may not even be able to perform an atomic operation if the data is not naturally aligned and only a limited number of datatypes are supported. This is common for RISC architectures.

PPC defines a weak memory (access) ordering that often requires sync memory barriers all over the place for SMP and may be the reason why SMP is still not working in AmigaOS 4. RISC weak memory ordering can cause problems for code written for CISC x86(-64). What other reason besides compatibility would RISC-V define an optional x86 like stricter Total Store Order (TSO)?

PPC code ends up with sync memory fences, load-reserve/store-conditional pairs, semaphore/mutex/spin lock protection, etc. that bloat up and slows down code near critical sections. Are there hardware choices that make programming easier and did PPC choose them?

tlosm Quote:

my G5 is alive like my C64... no sense reply for a no sense post.

The IBM 970 (G5) CPU is 2.9DMIPS/MHz and typically 66W at 2GHz using a 55nm process. The RPi 3 SBC with 4xCortex-A53@1.4GHz cores draws 5.661W max using a 40nm process. The Cortex-A53 single core performance is surprisingly close to the faster clocked G5 but the RPi 3 has more cores. The RPi 4 SBC with 4×Cortex-A72@1.8GHz cores uses 6.25W max with a 28nm process and has over double the single core performance of the G5 along with more cores. I don't even try to adjust the cost for inflation to make comparisons. The G5 is kind of like a Pentium 4 which can be used as a space heater in the winter.

bhabbott Quote:

Actually it was bit more than just 'some' assembler. OS 3.1 kickstart source has 526 .asm files totaling ~6 million characters, and 361 .c files totaling ~3.6 million chars. There are 98 asm files in graphics library with a total of 728 thousand characters, including code for blitter operations (blitbitmap etc.), sprites, copperlists, fonts and text rendering, region operations, and drawing functions (line draw, circle, flood fill etc.). DOS has 20 asm files totaling 338 thousand characters, covering such things as date strings, BCPL functions, loadseg, readargs, pattern matching, and the entire TRIPOS kernel (2847 lines of asm code). Console device has 27 asm files totaling 259 thousand characters, and a single .c file with only 338 lines of code. The filesystem, utility and keymap libraries are 100% asm code. And of course so is exec library, with 21 asm files totaling 527 thousand characters.

That is more 68k assembler than I thought for AmigaOS. More than half of the kickstart code is 68k assembler! It really does help to have readable assembler code.

bhabbott Quote:

In short, Amiga OS was riddled with asm code. Good luck translating that to ppc!

There already are several versions of most of the AmigaOS converted to C which can be compiled for PPC and all the bloated mess it makes. Goodbye small 68k AmigaOS footprint.

@matthey

Quote:

matthey wrote: That is more 68k assembler than I thought for AmigaOS. More than half of the kickstart code is 68k assembler! It really does help to have readable assembler code.

C source code tends to be a lot terser than assembler so those numbers might be a bit misleading. I'm guessing about 1/4 of the actual kickstart binary is asm. However when it come to porting it's the source code that matters. Translating assembler to C isn't trivial.

Quote:

bhabbott Quote: In short, Amiga OS was riddled with asm code. Good luck translating that to ppc! There already are several versions of most of the AmigaOS converted to C which can be compiled for PPC and all the bloated mess it makes. Goodbye small 68k AmigaOS footprint.

It took a lot of effort to get Amiga OS onto ppc and it isn't fully compatible. Porting classic Amiga code to OS 4 isn't trivial if it has any asm or hardware specific code in it.

ppc code takes up twice the space of 68k code. That isn't so much of a problem these days because we can throw gigibytes of RAM at a system relatively cheaply, but it's still disappointing. If you are one of the very few with a ppc board in a classic Amiga then it could well be an issue.

But the real question is WHY are we discussing this? Unless you are one of the few who have a ppc 'Amiga' it's pointless. And if you do when why are you whinging about 68k?

Normally I avoid OS 4 discussions because they are irrelevant to me, but in this case the OP assets that '"Classic" Amiga may run on any cpu' and that there are 'no reasons to use 68k. 68k gives nothing'. But we run 68k code on classic Amigas because they have a 68k CPU and the software expects a 68k CPU. That's a very good reason to use 68k - but not a good reason to discuss it here. This forum is about OS4 and ppc hardware, not 68k hardware.

OP says 'it is stupid to made software for emulator when simply switch to native code made everything run many times faster'. But emulating 68k is only done when running classic Amiga software that is designed to run on classic 68k Amiga hardware, where it is absolutely required. Vampire and PiStorm are ways of getting a faster 68k CPU into your classic Amiga - and that is all. How they do it internally (HDL or software emulation) is irrelevant. This has nothing to do with OS4, which runs natively on ppc.

AFAIK nobody is attacking ppc hardware. Nobody is stopping ppc 'Amiga' owners from porting C code to their systems. Nobody is preventing development of OS 4 and apps for it. Then the OP says there are 'no reasons to use aros on x86 or arm.' The OP complains about people 'attacking ppc' when they are doing the same to other platforms, telling us we have 'no reason' to use them.

@agami

Quote:

agami wrote: @cdimauro Quote: cdimauro wrote: @CosmosUnivers So, you're replying to THE parrot/troll of the forum with... this?!? Do you SERIOUSLY believe on what you're written or is it another joke? I see this as @ComosUnivers attempting to communicate with the parrot/troll using simple syntax and loose grammar that the parrot/troll might understand.

@fishy_fis

Quote:

fishy_fis wrote: @agami Quote: I see this as @ComosUnivers attempting to communicate with the parrot/troll using simple syntax and loose grammar that the parrot/troll might understand. That's how I perceived it as well. Hard to tell on this forum though. There's a little crazy in pretty much all of us here :)

Cosmos is the opposite of The Parrot/Troll: a die hard 68k fanatical.

That's why I think that he might have genuinely reacted that way.

Just my idea. But he didn't replied, albeit it has visited the forum and certainly saw my comment.

@bhabbott

Quote:

This forum is about OS4 and ppc hardware, not 68k hardware

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

This thread is in the "Amiga OS4 Hardware" forum section.

@pavlor

I see, I saw it from the start page... you're right

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@bhabbott

Quote:

Translating assembler to C isn't trivial.

Actually, it can be, if you experiment with that bit, like me, you know few tricks.
but it depends on what code is doing, if depends on hardware, if its just generic loops, copy routines etc. the problem is that’s its tricky to do it step by step, you need to do it more less in one operation. When you are working with disassembled code, you no good clues about what it does. Unless you start relabeling everything, and then you can start to understand bits and pieces. Some signatures are left behinds, like JSR -x(y), x value will the same in all libraries, so at number divisible by 6 (opcode 2 byes and address 4 bytes.), y register, does tell you anything, unless you can trace it back to the OpenLibrary function, some developers keep the lib bases in stack, and some push it to memory, if keep in stack, its not so easy to figure out, but if they push to address / label, you can rename the label. There really is lot work reverse engineer it to point you can even think about rewriting it to C. not wherry many assembler programmers will be able to understand disassembled machine code.

Last edited by NutsAboutAmiga on 17-Nov-2023 at 05:49 PM.

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

@bhabbott

Quote:

Porting classic Amiga code to OS 4 isn't trivial if it has any asm or hardware specific code in it.

Well, if just assembler, you probably get away calling EmulateTags() on code, without doing anything much with it, you need to compile as HUNK, and loaded into memory, and fix offsets etc. that’s probably easiest way. (I do support 680x0 asm i Amos banks, in Amos Kittens doing it like this)

Now if hardware specific code, it can depend on what code does, NallePuh can emulate some of it, but probably not the end result you like.

Copper can be rendered, with libCopper library you use for it, its slow and you really should consider rewriting the code. It does not have support for sprites.

Some planar coded, can easily be converted to chunky 8bit, and having palette lookup table, you can render it to a 32bit screen with more less the same end result as you see on planar screens. (As I do in Amos Kittens.)

Quote:

ppc code takes up twice the space of 68k code.

Not always, in the case of JMP its 6 bytes on 680x0, on PowerPC all instructions are 4 bytes.
so actually 66% of the size compared to 680x0, I must admit, you need load register with value to jump. So, it takes two instructions. That’s 8 bytes, but that’s not twice the size, compared to 6 bytes, It is really not that important, C code is bigger because of debug stuff, and standard libraries, if you compile without the standard libraries, and without the debug symbols, the exe files are often not that big. So blame GCC, and newlibs / clib, etc, not PowerPC, they are just as big on x64 and ARM.

another fun fact is that bigger code is often faster, take unrolled loops as an example. Optimizing for different CPU target can produce completely different results, a 680x0 CPU often not a lot instruction cache, so unrolling loops can infect make the code slower. But lets say you had a new super duper 68090 CPU with lots of instruction cache you most definitely want to unroll the loops, and that will make the code fat. So we are not really comparing apples to apples here.

We also talk about out of order execution, a nice technique, where if next instructions does not depend on the previous instruction can be executed in parallel, PowerPC with its 32 registers, can take advantage, by loading in values in series into R0,R1,R2,R4, etch, and the saving values R0,R1,R2,R4, because loading a value in R1, does not depend on value loaded into R0, parts of instructions can overlap, its complicated write code like that because you need to know what instructions benefits from out of order, and you know what instruction that collides. It’s actually not the syntax of PowerPC that’s most complicated, yes, their horrible names of a few instructions, most of it is understandable. A good compiler most often has better understanding of this things then an simple human does not. When hand write assembler code it can end up slower than a good C compiler, yes there are exceptions where the compiler sucks. But really its often a question of mastering the language, and giving the compiler the hints, to make the code faster. For example, you can tell arguments of function to be assigned to registers, or you can tell the iterators to be registers, you don’t need iterators often.

When comes down to fast code, it’s so often memory copy, stuff and table manipulation, reading in series of data into uninterrupted, can also reduce need for data cache flushes. If you have AltiVec its naturally the best tool in the PowerPC tool box, but as I wrote before its not the only tool.

Last edited by NutsAboutAmiga on 17-Nov-2023 at 06:30 PM.
Last edited by NutsAboutAmiga on 17-Nov-2023 at 06:25 PM.
Last edited by NutsAboutAmiga on 17-Nov-2023 at 05:57 PM.
Last edited by NutsAboutAmiga on 17-Nov-2023 at 05:56 PM.
Last edited by NutsAboutAmiga on 17-Nov-2023 at 05:54 PM.
Last edited by NutsAboutAmiga on 17-Nov-2023 at 05:52 PM.
Last edited by NutsAboutAmiga on 17-Nov-2023 at 05:48 PM.

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

@Thread

What happened to all the power that PPC was suppose to have? It’s seems kind of limp in 2023, painfully limp.

_________________
Sent from my Quantum Computer.

@DiscreetFX

It’s called Power, not PowerPC, same chip markers who make PowerPC for embedded also makes ARM chips. As everyone asking for ARM, and no one is asking for PowerPC anymore, development has halted.

IBM used to make PowerPC chips by cutting Power chips in half, so its not dead, dead, as long as IBM has interest in it, but other embedded chipset makers are as faithful as your x wife.

In any case the argument why its better to write 680x0 assembler over C or C++ does not hold water, in particular if want to port the OS to a different CPU.

And if the end gool is to port everything to C, it does not matter how fat the PowerPC binaries are, it’s the equivalent as to insulting a breast toaster. it has no meaning.

Last edited by NutsAboutAmiga on 17-Nov-2023 at 09:18 PM.
Last edited by NutsAboutAmiga on 17-Nov-2023 at 09:11 PM.

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

@DiscreetFX

There are no rational arguments for PPC today. The only thing it has going for it is that it runs OS4. The set of people well heeled enough to justify the exorbitant cost of entry is too small for there to be any real market to continue development of the OS, so it sits there stagnating. MOS manages to make some progress primarily because it's developed by a small, passionate team that would probably still be developing it even if nobody else used it. Neither is a viable approach in the long run.

PPC has done nothing for anyone here other than lock them in to super expensive niche hardware with no other progress, or lock them into sourcing and maintaining old PPC hardware.

Both OS4 and MOS would do well to drop the boat anchor.

_________________
Doing stupid things for fun...

There is one market where PowerPC may have a future and remain the processor of choice,

NASA / SPACE!

https://www.theverge.com/tldr/2021/3/2/22309412/nasa-perseverance-mars-rover-processor-cpu-imac-1998

So take that haters 😀

Also military seem to like to use PowerPC,
https://www.unmannedsystemstechnology.com/2022/06/new-sosa-aligned-powerpc-sbc-for-military-and-defense-applications/

Last edited by amigang on 17-Nov-2023 at 09:27 PM.

_________________
AmigaNG, YouTube, LeaveReality Studio