@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: I was recalling that strlen() checked if the argument was a null pointer and giving back 0 as its length, but looking around I've found no confirmation about it. On exact the contrary, the NetBSD implementation simply assumes that the pointer should not be null and immediately uses it. So, I'm not sure anymore if the above strdup is bugged or not. These functions come from a time when programmers understood that great power came with great responsibility. If you wanted a language that protected you from yourself then you used BASIC (and accepted the massive performance loss).

That doesn't make sense and only applies to Spider-Man.

In the real world you want to have all sort of protections which allows to make your life easy: here we're not masochists & narcissists like maynaf...

This clarified, the problem here is very different: strlen doesn't have a fully defined interface which tells you all cases about its argument and how it should behave. At least, I haven't found it looking around.
Quote:

In this case strdup() is taking the name of a file which has already been opened, so it must be valid.

Well, have you heard something like race conditions? Here's one case where it could apply.
Quote:

Why do another test inside it that just wastes time and memory?

I was referring to strlen, before. Anyway, in this specific case everything works, right.
Quote:

One of the reasons people don't like strdup() is that it allocates memory when other string functions don't. This can lead to memory leaks when people forget to free the memory. It can also cause memory fragmentation, which is a big problem on the Amiga.

"great power came with great responsibility"...
Quote:

Why is strdup considered to be evil Quote: It's not strictly ANSI C, but rather POSIX. Consequently, some compilers (e.g. MSVC) discourage use (MSVC prefers _strdup), and technically the C standard could define its own strdup with different semantics since str is a reserved prefix. So, there are some potential portability concerns with its use. It hides its memory allocation. Most other str functions don't allocate memory, so users might be misled (as you say) into believing the returned string doesn't need to be freed. That's the problem when you haven't a well defined interface or... people don't RTFM. Quote: But it's a pussycat compared to alloca()... Why is the use of alloca() not considered good practice? [quote]Q: alloca() allocates memory on the stack rather than on the heap, as in the case of malloc(). So, when I return from the routine the memory is freed. So, actually this solves my problem of freeing up dynamically allocated memory. Freeing of memory allocated through malloc() is a major headache and if somehow missed leads to all sorts of memory problems.

Indeed. Here you should really know very well what you're doing. alloca offers a great feature, but the price to pay could be very high.
Quote:

Why is the use of alloca() discouraged in spite of the above features? A: Not all compilers support alloca.

So, it's not part of the standard.
Quote:

Some compilers interpret the intended behaviour of alloca differently, so portability is not guaranteed even between compilers that support it.

And here comes the usual lack of a clear interface definition.
Quote:

Some implementations are buggy.

That's not a good reason for not using it: bugs... should be fixed!!!

@matthey

Quote:

matthey wrote: cdimauro Quote: Yes, that's what I've meant before, because I've immediately seen it when I've compiled (and just dumped to assembly) the Fibonacci example: machine 68030 opt o+,ol+,op+,oc+,ot+,oj+,ob+,om+ section "CODE",code public @fib cnop 0,4 @fib movem.l l6,-(a7) move.l d0,d3 moveq #1,d0 cmp.l d3,d0 blt l4 moveq #1,d0 bra l5 l4 move.l d3,d0 subq.l #2,d0 jsr @fib move.l d0,d2 move.l d3,d0 subq.l #1,d0 jsr @fib add.l d2,d0 l5 l6 reg d2/d3 movem.l (a7)+,d2/d3 l8 equ 8 rts machine 68030 opt o+,ol+,op+,oc+,ot+,oj+,ob+,om+ public @main cnop 0,4 @main movem.l l11,-(a7) moveq #3,d0 jsr @fib l11 reg l13 equ 0 rts This, added to what you've said, is a clear example that shows why the peephole optimizer should be moved to VBCC's backend. Another, even more important, example is embedding assembly code. This requires that the compiler does nothing: just report it as it is to the assembly. My expectation is that the assembler doesn't change it as well. However, how it could know that the assembled code was generated by the compiler or was just embedded? It can't, because it's missing this information which, on the other hand, was available to the compiler. In general, the compiler has much more metadata available which allows to take better decision when doing optimization, peephole ones include. Which, anyway, doesn't prevent to move some optimization the assembler's peephole. Yes, the code you posted is a good example of what I'm talking about. Tthe use of JSR instead of BSR is another backend simplification but vasm likely peephole optimizes this where possible. The vasm peephole optimization of branches and displacements is a success for Volker's backend simplification strategy but failing to add backend optimizations where peephole optimizations by the assembler can't be performed sabotages this strategy.

Which is strange, because this is a clear case where you can move the optimization to the assembler: just always generate a BRA for all branches and let the assembler try to generate this instruction, or convert it to a JSR.

It's exactly for situations like this that assemblers are still heavily used and are the preferred way to generate the final binary code: simplify the compiler's backend and move this burden to the multiple passes of the assembler.
Quote:

I had hope Volker would improve the 68k backend code generation quality when Individual Computers sponsored vbcc but, last I looked, most changes were bug fixes.

Maybe he has no time/interest anymore. He should seriously consider to put the source code to a repository to make contributions much easier (e.g.: he can just review the patches and merge them to the master branch).
Quote:

I considered writing a new 68k backend but this would take a long time, especially debugging, and there would be no guarantee Volker would replace the current one for the main vbcc distribution even if it was better (much like some 68k GCC backend efforts).

Why a new backend? Is the VBCC one so much difficult to understand & enhance?

BTW, debugging shouldn't be a great problem having a robust tests suite (which is very easy to create, maintain, expand).
Quote:

I believe a 68k instruction scheduler could optimize MOVEM instructions into MOVE instructions as it must track CC flags. This would be an unusual use of an instruction scheduler but it does follow Volker's strategy of simplifying the backend and better dividing the workload which potentially reduces memory use and offers better performance with SMP.

SMP is useful for optimizing the code to be generated. Nowadays many compilers use brute force to find the best combination by trying multiple patterns.
Quote:

Other optimizations could be performed as well. When compiling for size, an instruction scheduler for the 68020 ISA could combine instructions to use double memory indirect addressing modes for the cases which improve code density. The backend generating instructions using these addressing modes is bad as it limits instruction scheduling opportunities but the instruction scheduler could fuse instructions after determining no other instruction can be scheduled between. This optimization would be mostly for ultra code density bragging rights but my point is that some optimizations may be better performed by the scheduler.

Which is correct.
Quote:

cdimauro Quote: VBCC can be improved by taking those bad cases and taking a look at what SAS/C does. GCC 2.95.3 is the compiler 68k backend integer code generation to look at. It is very good although the FPU and support code are not as good. Vbcc 68k code generation for the FPU already beats every 68k compiler I'm aware of even though there is further room for improvement.

Then this doesn't need great changes. Good!
Quote:

Integer code is far more important though. If the vbcc 68k backend or (a new 68k instruction scheduler) performed the peephole optimizations that vasm can't, there wouldn't be many cases where SAS/C generated better quality code, at least for the 68020+.

Porting a good part of the peephole optimizer from vasm to VBCC could be the first thing to do.

A scheduler needs to be implemented on the backend, because it's not simply about shuffling generated instructions, but sometimes a different mix of instructions should be generated and here the brute force could help (and that's not something that an assembler could handle).
Quote:

SAS/C generated code tends to use small datatypes which more efficiently use registers while vbcc generated code often prefers to extend smaller datatypes to the register size which avoids partial registers stalls and is often better on the 68020+ and especially 68060.

I don't see the problem: both strategies could be used, depending on the specific context / section of code.
Quote:

The ColdFire MVS and MVZ instructions (MOVSX/MOVZX in x86) would provide great benefit to the vbcc 68k backend. The 68k backend already supports ColdFire and I worked with Frank to add ColdFire peephole optimization to vasm as well so the support just needs to be turned on. It's too bad these instructions didn't make it into the 68060 as they would have significantly improved performance and code density.

At least they can be used for the ColdFire... or the i386 (which is poor).
Quote:

cdimauro Quote: Having a bug/features tracking tool helps, but I haven't seen it for VBCC. I reported bugs to Frank which he tried to verify and determine where they come from. Frank is active on EAB and often answers vbcc and vasm related questions in the "Coders" section. I recalled the Mantis bug tracker being used somewhere but I couldn't find anything with a search. It's possible it is used internally.

Which is really bad: a public bug/feature tracker should be a must for any project.

There are so many things that show how VBCC is developed like a hobby project, lacking a more professional approach...

@Kronos

Quote:

Kronos wrote: @Karlos *shrug* For 68k you either rely on an 30 year piece of C= HW that is downgraded to a glorified KBD controller in most cases or you do full emulation which is just as much an option for PPC.

But with limited performance on PowerPCs.
Quote:

The question is what do you wanna do? Play ancient games? No OS or HW development needed.

It depends on which platform is your reference / preference. Specifically, many games need a very accurate chipset reproduction.

Which means that either you need big hardware development (if you hardware is your reference) or software development (if this is your reference). In the latter case you need a very powerful hardware to sustain the accuracy of emulation, which PowerPCs couldn't give.
Quote:

Play badly ported 20+ year old games? PPC is still the better option.

No, the original platform could be the better option (e.g.: PCs, usually).
Quote:

"Use" it as an everyday computer, nothing 68k even competes here.

No Amiga/-like platform can.
Quote:

We are kinda back to the platform wars, but while Amiga vs. Atari, PuP vs. WOS or Red vs Blue still had some entertainment value this round is just pathetic.

It's pathetic not accepting the reality, which specifically means the numbers: 68k is the platform which has WAY more software compared to the pallid imitations...
Quote:

Kronos wrote: @Karlos Erm, AMD64 is "a given" assuming anybody lives that long... While ARM may make some sense for fake-retro 68k turbos and and plastic EMU boxes

Plastic like TranceJIT?
Quote:

I just don't see as viable (in it's current form) for MorphOS_NG_4_JogurtBox.

That's normal, for fanaticals...

@MagicSN

Quote:

MagicSN wrote: @BigD At best my knowledge they cannot run Windows (not without Emulation) and do not use x86.

AFAIR they use x86 (running an emulator for its code) to interface with the graphics card's VGA BIOS (getting the list of video modes, setting a video mode, getting/setting the CLUT, getting the linear address of the framebuffer, etc.).
Quote:

So they are not PCs.

They are PCs with the only difference of the x86 CPU being replaced with a PowerPC one.

They even use some PC chipset in some cases.
Quote:

A PC is a computer with some sort of x86 which is able to run Windows (even if it actually might run Linux).

The PC was always an open software platform which wasn't limited to running Windows (which didn't even existed when they were introduced: only IBM/MS-DOS and CP/M86 were available).

So, basically it defines a hardware platform and a minimal software base (the BIOS): everything else it's up to the user.
Quote:

Since the 90s I always defined Amiga over the operating system, never over some extremely old chips.

Which is wrong: Amiga is clearly defined AND includes the chipset, as well as a CPU from the Motorola 68k family.

Nothing else can be defined as "Amiga". Which, as a simple logical consequence, means that a "PowerPC Amiga" doesn't and cannot exists as well.

I assume that you've never read Commodore's documentation, right?


@Hammer

Quote:

Hammer wrote: @ppcamiga1 Quote: ppcamiga1 wrote: what I see here is some pople as usually not accept reality. there is nothing special in 68k except it works in 32 bit big endian mode. beyond that 68k is cpu like many other. Big Endian 68K has good code density.

Even better: it's an architecture which has one of the best code density.

@Hypex

Quote:

Hypex wrote: @NutsAboutAmiga Quote: 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. Internally Exec could do that. Externally it could be a problem since the method is disabling all interrupts. At this point 68K code shouldn't be allowed to do it for real and even native code disabling interrupts should should be depreciated in favour of a safer method.

It's too late: it was perfectly legit to disable/enable the multitasking and even the interrupts.

Plus, most of the software is now available only in binary form, so it can't be patched.

Amiga, as a platform, is well defined and we've to take it as it is.

If you want something more then it's better to define another platform, even greatly inspired to Amiga, but which will be different and running different software.
Quote:

Hypex wrote: @matthey Quote: 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. What I wonder is for long it's been on the market. There's talk online it's relatively new and other talk it's been on the market for a while and scaling up. And, being called RISC-IV,

It's RISC-V, not RISC-IV.
Quote:

what happened to the previous 4 versions?

They were mostly academic projects. RISC-V is simply the fifth RISC core coming from Berkeley.
Quote:

It looks like the closest competitor to Power. While Power seems to have disappeared and even a basic search on RISC server CPUs reveals no mention of Power still being around but does mention ARM and RISC-IV servers.

POWER has no competitor because it's another dying horse, like PowerPC: it has absolutely no appealing point / features compared to the other CPUs, besides a software library and support which are coming since some decades.
Quote:

Quote: 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. I wonder how it works around it.

By masking the data which isn't used (and should be left untouched).
Quote:

Quote: 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)? Interesting it does that in a similar way. The main problem is the data protection design to lock the whole system down. Any Forbid needs to lock all cores down from running any tasks. I suppose it could just do that. But it affects the system so where there are attempts for over a decade to work around it since it's a difficult issue.

It's not only about Forbid/Permit and Disable/Enable: it's about ANY code which is touching their specific counters which should be intercepted and treated accordingly.

Which means: FORGET IT! It's too hard work because there's simply too much software which did it (and it was LEGIT!).
Quote:

Quote: The G5 is kind of like a Pentium 4 which can be used as a space heater in the winter. But unlike the P4 the G5 is 64-bit

Wrong: the last P4s were 64 bits.
Quote:

Hypex wrote: @cdimauro Quote: Because Forbid/Permit, Disable/Enable and their ridiculous 8 bit counters are clear examples of why the Amiga o.s. BadByDesign. It's also unusual as in other places like a library it's a UWORD. So some what consistent.

What's consistent with the Amiga o.s. is that it was written by geeks which made what for them were local optimal choices for solving a specific problem. And with the hurry to finish the work ASAP because of the deadline.

This lead to so many bad design decisions, unfortunately.
Quote:

I'm no expert on system design but to me, looking at it in hindsight, it's looks like bad design to lock the whole task system down for one task needing to share or protect data. Of course, the OS is open by design, so not only allows but also encourages user programs to peek and poke around in core OS structures.

Guess why the Amiga o.s. was so lightweight: it's because it completely lacked any protection / abstraction. Do you need something? Do it! Everything is public and you can do whatever you want (well, there were some guidelines, but that's very little stuff compared to the "openess" of the platform).
Quote:

Any shareable object needing protection should have had a dedicated embedded structure with an associated access function that locked it out. At least that's what I think. Even a Forbid/Disable type counter could have worked for local data.

Exactly.
Quote:

Memory was tight but it wouldn't have needed much.

Indeed. They (the engineers) were so many focuses on optimizing that they completely lost the contact with the reality and "optimized" even where it should haven't been the case.
Quote:

Oh, lol. https://execlibrary.com

Quote:

Quote: Well, this is not "a blog": it's THE blog. Raymond Chen is simply amazing! I stumbled upon it by accident. Whatever I was looking for an MS site was the last place I expected to find an article about PPC. But it was the most informative article I had found on the subject regarding PPC.

And not only that: Reymond's blog is simply a mine full of wonderful things to discover!

@hammer

Quote:

Big Endian 68K has good code density

Only the purple ceramic ones.

What? The packaging colour is as relevant to the code density as the endianness is...

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: @hammer Quote: Big Endian 68K has good code density Only the purple ceramic ones. What? The packaging colour is as relevant to the code density as the endianness is...

Just a couple of seconds to get it:
https://www.youtube.com/results?search_query=risc-v+code+density&sp=CAI%253D

@Density fanatics



It seemed to me as if old x86 programs where more compact, especially those with the extension 'com' .

X86 was an improved 8-bit CPU and very good in single byte handling, something very important back in this times.

Edit:
8-byte chip -> 8-bit CPU

Last edited by OneTimer1 on 02-Dec-2023 at 01:23 PM.

@OneTimer1

https://i.imgflip.com/87xwow.jpg

_________________
Doing stupid things for fun...

@cdimauro

Quote:

cdimauro wrote: @Hypex It's too late: it was perfectly legit to disable/enable the multitasking and even the interrupts.

Yes, it's too late. But not because it can't be changed. The Amiga is now retro. We don't want to change it.

disable/enable is done by poking the custom chip interrupt enable register. This hardware could easily be changed to do something else. Forbid and permit are OS calls. The OS can do what it wants it with them.

These aren't insurmountable limitations, there's just no point doing anything about them.

Quote:

Plus, most of the software is now available only in binary form, so it can't be patched.

Thousands of WHDLoad slaves say otherwise. Most Amiga software can easily be patched by disassembling and reassembling it.

Quote:

Amiga, as a platform, is well defined and we've to take it as it is.

Yep. No need to fret over it not having modern OS features - we don't need them! We don't want them!

Quote:

Guess why the Amiga o.s. was so lightweight: it's because it completely lacked any protection / abstraction. Do you need something? Do it! Everything is public and you can do whatever you want (well, there were some guidelines, but that's very little stuff compared to the "openess" of the platform).

No memory protection hardware means there was no way to hide anything anyway, so why try? We appreciated the openness.

Quote:

They (the engineers) were so many focuses on optimizing that they completely lost the contact with the reality and "optimized" even where it should haven't been the case.

Not sure what you mean by this. RAM and ROM was tight, so optimization was necessary - the more the better. KS2 and 3 had a lot of stuff 'downcoded'; from C to asm to save space in the ROM.

We should not forget that the Amiga was originally designed to be a games console - and this is largely what it was used for. They added a nifty multitasking OS, but it was not intended to be a multi user system with all the protections that would need. There was nothing wrong with that, and there still isn't.

Amiga OS did have some serious problems, but openness wasn't one of them. The biggest problem was lack of functions for doing stuff people needed, resulting in nasty hacks and code that only worked by fluke. Some of this was fixed in KS2. Other problems included poor documentation and bugs that made it difficult to get things right.

Amiga OS started out in a very unfinished state, and wasn't right even 2 years later. If only some of us had been on the team....

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: @Hypex It's too late: it was perfectly legit to disable/enable the multitasking and even the interrupts. Yes, it's too late. But not because it can't be changed. The Amiga is now retro.

It can't be changed if the goal is 100% backward-compatibility (which is obviously implicit).
Quote:

We don't want to change it.

Why you always resort to "we" when you desperately try to defend your toy? It's YOU, NOT we!
Quote:

disable/enable is done by poking the custom chip interrupt enable register. This hardware could easily be changed to do something else. Forbid and permit are OS calls. The OS can do what it wants it with them.

Wrong: there's an 8-bit counter for Disable/Enable as well:
http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_2._guide/node009E.html#line31
BYTE IDNestCnt; /* interrupt disable nesting count */
Quote:

These aren't insurmountable limitations,

They are: se above.
Quote:

there's just no point doing anything about them.

Here I agree.
Quote:

Quote: Plus, most of the software is now available only in binary form, so it can't be patched. Thousands of WHDLoad slaves say otherwise. Most Amiga software can easily be patched by disassembling and reassembling it.

Easily? Then go on!
Quote:

Quote: Amiga, as a platform, is well defined and we've to take it as it is. Yep. No need to fret over it not having modern OS features -

It depends on the features: some modern feature can be added.
Quote:

we don't need them! We don't want them!

See above: why don't you talk only for YOURSELF?!?
Quote:

Quote: Guess why the Amiga o.s. was so lightweight: it's because it completely lacked any protection / abstraction. Do you need something? Do it! Everything is public and you can do whatever you want (well, there were some guidelines, but that's very little stuff compared to the "openess" of the platform). No memory protection hardware means there was no way to hide anything anyway, so why try?

That's completely illogical, Bruce: an o.s. can have a Good Design (TM) even WITHOUT any hardware protection.

If you make Bad Design decision because you have no protection you're crippling the o.s. future.
Quote:

We appreciated the openness.

See above: why don't you talk only for YOURSELF?!?
Quote:

They (the engineers) were so many focuses on optimizing that they completely lost the contact with the reality and "optimized" even where it should haven't been the case.

Not sure what you mean by this.[/quote]
I already gave you an example about the 8-bit counters for multitasking and interrupt.

Do you want more? Embedding 8 pointers in the BitMap for the bitplanes, embedding the BitMap on the RastPort, using the MSB on AllocEntry to signal a failure on memory allocation, etc. (you can open the ROM Kernel Manuals and enumerate all cases of Bad Design decisions by yourself, buy checking the o.s. structures & APIs).
Quote:

RAM and ROM was tight, so optimization was necessary - the more the better. KS2 and 3 had a lot of stuff 'downcoded'; from C to asm to save space in the ROM.

Optimizations do NOT necessarily mean taking Bad Design decisions.
Quote:

We should not forget that the Amiga was originally designed to be a games console -

Which it was NOT!
Quote:

and this is largely what it was used for.

How many games were available when it was first released? And how many applications?
Quote:

They added a nifty multitasking OS, but it was not intended to be a multi user system with all the protections that would need.

I reveal you another of my (long list of) secrets: you don't protections to implement a Well Designed o.s..

A clear example is MINIX: it was first developed on/for 8088/8086 systems, which had no protection at all and not even a supervisor mode...
Quote:

There was nothing wrong with that, and there still isn't.

Here I agree: there's nothing wrong lacking multiuser and something like that. What's wrong is designing an o.s. taking Bad Decisions which then doesn't allow to implement it.
Quote:

Amiga OS did have some serious problems, but openness wasn't one of them.

It's the exact opposite: it was its primary problem.
Quote:

The biggest problem was lack of functions for doing stuff people needed, resulting in nasty hacks and code that only worked by fluke.

Again, you show a wrong and pervert "logic": since something is missing then nasty things are allowed.

NO, FUNNY NO!!!
Quote:

Some of this was fixed in KS2. Other problems included poor documentation

The RKM were good enough at the time.
Quote:

and bugs that made it difficult to get things right.

Bugs can and should be fixed! This should NOT justify doing nasty things, anyway!
Quote:

Amiga OS started out in a very unfinished state, and wasn't right even 2 years later.

That's ok.
Quote:

If only some of us had been on the team....

Oh, no, please: at least not you with your odd mentality. You could have made the situation even worse!

Go play directly with the hardware on an old console: that's your favorite environment.

Hypex Quote:

I wonder how it works around it. The atomics don't look the best either with busy looping until a lock. If it's taken. But, they've somehow the old counters to work, by what ever means.

A semaphore or other locking mechanism can be required before changing the (unaligned) counter and released afterward.

Hypex Quote:

Interesting it does that in a similar way. The main problem is the data protection design to lock the whole system down. Any Forbid needs to lock all cores down from running any tasks. I suppose it could just do that. But it affects the system so where there are attempts for over a decade to work around it since it's a difficult issue.

On a Forbid, other SMP cores need to empty the pipeline, flush the store buffer and stall on any globally available memory access. Deeper pipelines, a weak memory model and OoO make this more expensive. Custom hardware may be able to reduce the overhead but SMP support with older software would be a kludge at best while newer software could avoid Forbid with better APIs.

cdimauro Quote:

Why a new backend? Is the VBCC one so much difficult to understand & enhance?

A new 68k backend could be developed and distributed independently without the ok of the maintainer. It's the same concept as the development of the 68k backend for GCC where the GCC developers barely want to maintain it and don't want to be bothered to improve it. The GCC 68k backend was nearly dropped and it was only retained because money was raised for a developer to update it to the newer API.

cdimauro Quote:

Then this doesn't need great changes. Good!

The GCC 68k backend quality deteriorated quickly with API changes. GCC 2.95.3 was the peak for the integer code generation quality. Up to about GCC 3.3, there was some improvement in the support code and C standard supported but also some bugs introduced and a small decline in the integer code generation quality. GCC 3.4 saw another big API change and improvement in the compiler frontend but the 68k backend code generation looked like it was from a different compiler and was average at best. This continued up through GCC 4 with some improvement around GCC 5 or 6. The C standards and GCCisms supported by GCC 2 and 3 are not good enough to compile many programs today. Vbcc is a more modern C compiler but doesn't support GCCisms or C++.

cdimauro Quote:

I don't see the problem: both strategies could be used, depending on the specific context / section of code.

Sometimes using smaller datatypes is better but it is best to avoid partial register stalls and the 68060 can only forward/bypass 32 bit results.

cdimauro Quote:

At least they can be used for the ColdFire... or the i386 (which is poor).

The 68k and ColdFire are supported by the same backend and assembler configuration so the vasm peephole optimizations improve ColdFire code. It didn't help i386 code and peephole optimizations are likely not possible due to the larger MOVSX and MOVZX instructions. MVS and MVZ reduce the number of instructions and improve code density for ColdFire and 68k code.

cdimauro Quote:

Just a couple of seconds to get it: https://www.youtube.com/results?search_query=risc-v+code+density&sp=CAI%253D

I actually checked out one of the several RISC-V code density links from your search.

https://youtu.be/cT61fA_sIlo?t=71 Quote:

When trying to compare the normal RISC-V code size density and code size performance against other commercial ISAs, we found that it's considerably worse like 20-25% even with a compressed extension that it provides which is for the 16 bit, which is, so there is a compressed extension that provides a set of 16 bit instructions that should help with the code size but even with that the application code size are often much larger than ARM like that than alternative commercial processors like ARM.

The video is about using some of the large user customizable encoding space to define more compressed instructions called RISC-V ZCE Extensions. What did they come with for instructions?

Overview of added instructions (CISC instructions for RISC-V?)
https://youtu.be/cT61fA_sIlo?t=1015

TBLJAL (weak addressing modes and limited branch displacement bits so jump table instruction)
https://youtu.be/cT61fA_sIlo?t=1213

PUSH, POP, POPRET (names more like x86 instructions but actually more like 68k MOVEM)
https://youtu.be/cT61fA_sIlo?t=1534

MULIADD, MULI and ADDIADD (for calculating array indexes like CISC addressing modes)
https://youtu.be/cT61fA_sIlo?t=1670

The answer to considerably worse code density than ARM (Thumb2) is to add CISC features that were copied from the 68k (and Thumb2 with heritage from the 68k). They can probably improve the code density some and reducing the number of instructions may even improve performance but they will still have half the performance of executing instructions with an EA calc and ALU operation in the same instruction pipeline of the SiFive U74 core. Could anyone be more proud of reinventing inferior technology to superior technology which was thrown away? Do people have trouble seeing the obvious?

OneTimer1 Quote:

It seemed to me as if old x86 programs where more compact, especially those with the extension 'com' . X86 was an improved 8-byte chip and very good in single byte handling, something very important back in this times.

Yes, 808x and x86 code is sometimes smaller than 68k code when using byte datatypes in small programs. Many small instructions which often access the stack make this possible even though it is not good for performance. This is what x86 is encoded and specialized for.

Last edited by matthey on 02-Dec-2023 at 07:43 AM.
Last edited by matthey on 02-Dec-2023 at 07:37 AM.

@cdimauro

Quote:

cdimauro wrote: It can't be changed if the goal is 100% backward-compatibility (which is obviously implicit).

100% backwards compatibility was never implicit.

Quote:

Why you always resort to "we" when you desperately try to defend your toy? It's YOU, NOT we!

Yes, it is 'we' - by which I mean retro computer enthusiasts. You guys who want to add SMP to to 'Amiga' OS? That's your problem.

Quote:

Wrong: there's an 8-bit counter for Disable/Enable as well:

So?

Quote:

I already gave you an example about the 8-bit counters for multitasking and interrupt.

There's nothing wrong with that.

Quote:

Do you want more? Embedding 8 pointers in the BitMap for the bitplanes, embedding the BitMap on the RastPort, using the MSB on AllocEntry to signal a failure on memory allocation

Nothing wrong with any of that either.

Quote:

Quote: We should not forget that the Amiga was originally designed to be a games console - Which it was NOT!

Yes, it was. Perhaps you should read up on the history of the Amiga.

Quote:

Quote: Amiga OS did have some serious problems, but openness wasn't one of them. It's the exact opposite: it was its primary problem. Quote: The biggest problem was lack of functions for doing stuff people needed, resulting in nasty hacks and code that only worked by fluke. Again, you show a wrong and pervert "logic": since something is missing then nasty things are allowed.

'Nasty things being allowed' was standard practice for hobbyist computers of the time. Attempts to lock us out were not appreciated. You may have noticed that the vast majority of Amiga games kick out the OS as soon as possible. It took a long time - too long - for the Amiga OS designers to understand the significance of this.

Theses six of one and half a dozen of the other. For people that want to have a pure retro experience, they can stick to 3.1, the last official commodore release. For people that want to have new features, bug fixes etc, well, there's 3.5, 3.9 and - only Amiga makes it possible - 3.1.4 and 3.2

In order to continue to improve the latter, it may be necessary to abandon certain old practises. If you don't want that improvement, don't upgrade and keep on doing what you love.

I don't really see what the issue here is. Choose your poison and stick with it.

_________________
Doing stupid things for fun...

@Karlos

Here is something interesting,

https://global.chinadaily.com.cn/a/202311/30/WS6567d498a31090682a5f0aa2.html


Wol..

_________________
It is my conviction that killing under the cloak of war is nothing but an act of murder.~Albert Einstein

Quote:

Wol wrote: Here is something interesting, https://global.chinadaily.com.cn/a/202311/30/WS6567d498a31090682a5f0aa2.html

Quote:

Hu Weiwu, chairman of Loongson Technology, said the fundamental way forward for China's information industry lies in building an independent ecosystem outside of the X86 and ARM systems

Alright!

Finally a way to modernize the Amiga while keeping Intel (and ARM) outside. But can it do big-endian?

bhabbott Quote:

Finally a way to modernize the Amiga while keeping Intel (and ARM) outside. But can it do big-endian?

Don't count on it. MIPS is bi-endian with most old cores using big endian but it looks like little endian is the default for Loongson.

https://www.debian.org/ports/mips/ Quote:

o SGI Indy with R4x00 and R5000 CPUs, and Indigo2 with R4400 CPU (IP22). o SGI O2 with R5000, R5200 and RM7000 CPU (IP32). o Broadcom BCM91250A (SWARM) evaluation board (big and little-endian). o MIPS Malta boards (big and little-endian, 32 and 64-bit). o Loongson 2e and 2f machines, including the Yeelong laptop (little-endian). o Loongson 3 machines (little-endian). o Cavium Octeon (big-endian).

Full bi-endian support may still be in hardware but I wouldn't count on it remaining. There is at least one active Broadcom MIPS SoC that uses big endian by default. There are others but the default is likely little endian although they may have full support for big endian in hardware. Most of the big endian MIPS cores are as old as PPC cores. ARM cores are a more modern source of big endian hardware but big endian support is disappearing from newer cores. Some chips will use older ARM cores for many years but they will fall behind in performance.

RISC-V defined big endian support but it doesn't look very good.

https://reviews.llvm.org/D128612 Quote:

Implement riscv32be and riscv64be targets. The RISC-V big- and bi-endian targets are discussed in the RISC-V spec Version 20191213, but some aspects, like ABI are still unclear. The instruction encoding is little endian in both big- and little-endian modes. ISA spec Volume 1 1.15: "Instructions are stored in memory as a sequence of 16-bit little-endian parcels, regardless of memory system endianness". RISC-V Big-endian cores are already supported by GCC. Where spec is unclear, we aim to be compatible with GCC.

There isn't a RISC-V big endian ABI or implementation yet but GCC already has support. They tried to drop 68k support though.

RISC-V being natively little endian means the code is little endian which we find from the manual.

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-118.pdf Quote:

We chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and so we leave open the possibility of non-standard big-endian or bi-endian systems. We have to fix the order in which instruction parcels are stored in memory, independent of memory system endianness, to ensure that the length-encoding bits always appear first in halfword address order. This allows the length of a variable-length instruction to be quickly determined by an instruction fetch unit by examining only the first few bits of the first 16-bit instruction parcel. Once we had decided to fix on a little-endian memory system and instruction parcel ordering, this naturally led to placing the length-encoding bits in the LSB positions of the instruction format to avoid breaking up opcode fields.

The funny thing is that the opcode was placed at the end of the instruction so that it appears at a lower address in little endian memory for faster decoding. "Naturally"! Not!

Last edited by matthey on 02-Dec-2023 at 10:02 PM.
Last edited by matthey on 02-Dec-2023 at 09:19 PM.

@matthey

Quote:

matthey wrote: cdimauro Quote: Why a new backend? Is the VBCC one so much difficult to understand & enhance? A new 68k backend could be developed and distributed independently without the ok of the maintainer. It's the same concept as the development of the 68k backend for GCC where the GCC developers barely want to maintain it and don't want to be bothered to improve it. The GCC 68k backend was nearly dropped and it was only retained because money was raised for a developer to update it to the newer API.

I see two problems then.

First is that the you need anyway to follow the VBCC changes and adapt your new backend as well. So, something like GCC could happen (albeit it's unlikely, since I don't see many progresses on VBCC), and rebasing each time the changes could be a nightmare.

Second is the copyright: VBCC is not open and even if you create a new backend for it then you're not allowed to release products based on VBCC without a permission / agreement with the author.
Quote:

cdimauro Quote: Then this doesn't need great changes. Good! The GCC 68k backend quality deteriorated quickly with API changes. GCC 2.95.3 was the peak for the integer code generation quality. Up to about GCC 3.3, there was some improvement in the support code and C standard supported but also some bugs introduced and a small decline in the integer code generation quality. GCC 3.4 saw another big API change and improvement in the compiler frontend but the 68k backend code generation looked like it was from a different compiler and was average at best. This continued up through GCC 4 with some improvement around GCC 5 or 6. The C standards and GCCisms supported by GCC 2 and 3 are not good enough to compile many programs today.

Yes, but Bebbo has a more modern version and with a much better backend: AFAIR it's better than the 2.95.

The only thing that I don't understand (or I simply don't know if there are some reasons) is why its changes aren't upstreamed.
Quote:

Vbcc is a more modern C compiler but doesn't support GCCisms or C++.

The main problem is the lack of C++ support. Which is ok: C++ is a monster with big developments: it requires HUGE effort even for supporting some old version.

Which, unfortunately, restricts VBCC audiance.
Quote:

cdimauro Quote: cdimauro [quote] At least they can be used for the ColdFire... or the i386 (which is poor). The 68k and ColdFire are supported by the same backend and assembler configuration so the vasm peephole optimizations improve ColdFire code. It didn't help i386 code and peephole optimizations are likely not possible due to the larger MOVSX and MOVZX instructions. MVS and MVZ reduce the number of instructions and improve code density for ColdFire and 68k code.

Yes, but maybe something could be borrowed for enhancing the i386 backend.

68k / ColdFire is clearly the best supported platform in VBCC.
Quote:

cdimauro Quote: Just a couple of seconds to get it: https://www.youtube.com/results?search_query=risc-v+code+density&sp=CAI%253D I actually checked out one of the several RISC-V code density links from your search. https://youtu.be/cT61fA_sIlo?t=71 Quote: When trying to compare the normal RISC-V code size density and code size performance against other commercial ISAs, we found that it's considerably worse like 20-25% even with a compressed extension that it provides which is for the 16 bit, which is, so there is a compressed extension that provides a set of 16 bit instructions that should help with the code size but even with that the application code size are often much larger than ARM like that than alternative commercial processors like ARM. The video is about using some of the large user customizable encoding space to define more compressed instructions called RISC-V ZCE Extensions. What did they come with for instructions? Overview of added instructions (CISC instructions for RISC-V?) https://youtu.be/cT61fA_sIlo?t=1015 TBLJAL (weak addressing modes and limited branch displacement bits so jump table instruction) https://youtu.be/cT61fA_sIlo?t=1213 PUSH, POP, POPRET (names more like x86 instructions but actually more like 68k MOVEM) https://youtu.be/cT61fA_sIlo?t=1534 MULIADD, MULI and ADDIADD (for calculating array indexes like CISC addressing modes) https://youtu.be/cT61fA_sIlo?t=1670 The answer to considerably worse code density than ARM (Thumb2) is to add CISC features that were copied from the 68k (and Thumb2 with heritage from the 68k). They can probably improve the code density some and reducing the number of instructions may even improve performance but they will still have half the performance of executing instructions with an EA calc and ALU operation in the same instruction pipeline of the SiFive U74 core. Could anyone be more proud of reinventing inferior technology to superior technology which was thrown away? Do people have trouble seeing the obvious?

Indeed and it was really fun watching the video (I already know and studied the ZCe extension): it's clear admission that RISC-V sucks at code density (20-25% worse is a HUGE difference!).

It's ever more fun when I think that its great architects reserved beforehand 75% of the opcode space only for the compressed / 16-bit instructions. And they, still, failed...

Anyway, this is a testament of the fact that CISC was and still is a much better macroarchitecture family compared to RISCs.

BTW, here are the statistics:
https://docs.google.com/spreadsheets/d/1bFMyGkuuulBXuIaMsjBINoCWoLwObr1l9h5TAWN8s7k/edit#gid=1679419155
It's evident that the biggest contributes to the code density improvements are coming from the PUSH/POP with multiple registers and the ability to call "far" subroutines.
The first is an advantage that 68ks had since the beginning. The second is common for almost any CISC architecture.

Again, a testament of how much better CISCs are...

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: cdimauro wrote: It can't be changed if the goal is 100% backward-compatibility (which is obviously implicit). 100% backwards compatibility was never implicit.

No? How do you think to implement SMP without drastically dropping the compatibility with the existing applications?

There were plenty of them which directly accessed the o.s. structures because there was no other way to do it, as you are proud of!
Quote:

Quote: Why you always resort to "we" when you desperately try to defend your toy? It's YOU, NOT we! Yes, it is 'we' - by which I mean retro computer enthusiasts.

Well, I'm also a retro enthusiast AND I do NOT share your opinion! So, it's, again, YOU and NOT we!
Quote:

You guys who want to add SMP to to 'Amiga' OS? That's your problem.

You? Who? Did I state it? Where?

Do you see that you've a completely distorted vision and try to apply "we" and "you" labels which have no sense?
Quote:

Quote: Wrong: there's an 8-bit counter for Disable/Enable as well: So?

So you don't understand the implications of having just 255 possible values for it...
Quote:

Quote: I already gave you an example about the 8-bit counters for multitasking and interrupt. There's nothing wrong with that.

OK, nevermind: I forgot that you're a blind fanatical which justifies anything coming from Commodore...
Quote:

Quote: Do you want more? Embedding 8 pointers in the BitMap for the bitplanes, embedding the BitMap on the RastPort, using the MSB on AllocEntry to signal a failure on memory allocation Nothing wrong with any of that either.

Same as above: you're hopeless!
Quote:

Quote: [quote]We should not forget that the Amiga was originally designed to be a games console - Which it was NOT!

Yes, it was. Perhaps you should read up on the history of the Amiga.[/quote]
I know it very well. As well as I know that the o.s. development was delaying the release of the machine.

An o.s. blocking a game machine... on 1985, where no o.s. and directly hitting the hardware was the only way for games...
Quote:

Quote: [quote]Amiga OS did have some serious problems, but openness wasn't one of them. It's the exact opposite: it was its primary problem. Quote: The biggest problem was lack of functions for doing stuff people needed, resulting in nasty hacks and code that only worked by fluke. Again, you show a wrong and pervert "logic": since something is missing then nasty things are allowed.

'Nasty things being allowed' was standard practice for hobbyist computers of the time.[/quote]
Only if there were NO guidelines for the development.

Otherwise only an idiot could have ignored them and done nasty things.
Quote:

Attempts to lock us out were not appreciated.

"us"? Again, you should talk for YOURSELF!

I've diligently followed Commodore's guidelines! And that should have been the NORMAL thing to do!
Quote:

You may have noticed that the vast majority of Amiga games kick out the OS as soon as possible. It took a long time - too long - for the Amiga OS designers to understand the significance of this.

No, here it's clearly that you never understood how the Amiga worked and you never have read Commodore's guidelines.

That's because you were allowed to kick out the o.s. AND develop games (or anything) WITHOUT doing nasty things. It should have been enough to follow the SPECIFIC guidelines for THOSE cases. Which were reported on a couple of pages of the Amiga Hardware Manual (which you've never read it, evidently).

@matthey

Quote:

matthey wrote: RISC-V being natively little endian means the code is little endian which we find from the manual. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-118.pdf Quote: We chose little-endian byte ordering for the RISC-V memory system because little-endian systems are currently dominant commercially (all x86 systems; iOS, Android, and Windows for ARM). A minor point is that we have also found little-endian memory systems to be more natural for hardware designers. However, certain application areas, such as IP networking, operate on big-endian data structures, and so we leave open the possibility of non-standard big-endian or bi-endian systems. We have to fix the order in which instruction parcels are stored in memory, independent of memory system endianness, to ensure that the length-encoding bits always appear first in halfword address order. This allows the length of a variable-length instruction to be quickly determined by an instruction fetch unit by examining only the first few bits of the first 16-bit instruction parcel. Once we had decided to fix on a little-endian memory system and instruction parcel ordering, this naturally led to placing the length-encoding bits in the LSB positions of the instruction format to avoid breaking up opcode fields. The funny thing is that the opcode was placed at the end of the instruction so that it appears at a lower address in little endian memory for faster decoding. "Naturally"! Not!

Why? Actually the opcode IS at the beginning of the instruction (LSBs): not at the end.