@Hypex

i have heard that mantra, lets be blunt, many times before. if you really want to artificially restrict yourself trying to use some kind of amiga related system, just for the sake of it, while you would have been better off just using a pc standing next to it, to fulfil your task, so be it.

as example, i have heard many times, how problematic it is to compile odyssey on an os4 system, because of cmake, other tools, because it takes long, because this or that. now, i can build odyssey for whatever target im using on linux using its multi threading capabilities. why would i even insist on doing it on non-smp aros, considering the size and complexity of the project?

@matthey
Quote:

If mapping 8 more data registers using the free An in most EAs, then both source and data would be wanted. With a 68k 64 bit mode, this can be done more cleanly but there are a few instructions using the address registers which need new versions. The non-EA register fields are only 3 bits (0-7) meaning using two d8-d15 registers in many common instructions (and sometimes one with for example SUB) is not possible and it would be unclear when a prefix or longer instruction would be necessary for these cases. IMO, it would be uglier (and decrease code density) than opening up An register sources which reduces the number of instructions, improves code density, improves orthogonality and can be done practically for free. IMO, if you want more registers, the prefix method by itself is cleaner although still ugly. The advantage here is being able to use register ports which are the same for both 32 and 64 bit mode. Otherwise, instruction level compatibility would be enough and a 64 bit SuperCISC ISA could be made which would map most 68k and x86/x86_64 instructions.

Using a prefix doesn't require changing a mode, it could be supported even in a pure 32 bit design with the 64 bit extension encoding reserved. Not even extending the number of registers require a mode change but it would require the context switch code of the OS saving/restoring all registers.

Using address register sources have no advantage compared to a prefix+extended D register sources when it comes to compatibility, programs have to be updated to use both versions.
Using a prefix+normal instruction to initialize "constants" in the higher D registers and then using them as sources uses the same amount of bytes as using integer instructions+MOVE to A registers and then using these as sources, there is no advantage there. The later would also require more instructions potentially lower performing.
Accessing the high D registers like this also preserves the A registers which otherwise would be used as integer data.

So if there is prefix support already using An source encodings as Dn+8 sources is IMHO better.
Quote:

There is no use for an "Address Register Indirect Full Format with Predecrement". forward_old: lea (8,a0),a0 addq.l #1,(a0)+ clr.l (a0)+ forward_new: addq.l #1,(8,a0)+ ; base register update + 4 clr.l (a0)+ reverse_old: lea (12,a0),a0 clr.l (a0) addq.l #1,-(a0) reverse_new: clr.l (12,a0)! ; base register update (predecrement unnecessary) addq.l #1,-(a0) An advantage is decreased number of instructions. It is possible to improve code density in performance code avoiding several (d,An) addressing modes although there is a potential to reduce code density in some short sequences. The full format addressing modes are more complex to decode and execute but the Apollo core is able to do most of them for free (no EA calc delay). This favorable of timing makes them more appealing but adding them would require bigger muxes and could slow decoding and/or the AGU. That is what I need to know. Is there a way to do it practically for free? It would be possible to scale displacements by the instruction size giving a larger range of displacement in 64 bit mode which would also require more EA calc work. I may need the bits in the full format extension for better 32 bit compatibility in 64 bit mode anyway. My ISAs are for evaluation purposes and give a visual idea of some less than conservative ideas. Perhaps someone will see the idea, like it and figure out a way to gain an advantage. Perhaps it will be gone in a new ISA for evaluation from me.

Nothing is ever free.

What I ask is what the use cases is for these operations are and if they will be used so often that complicating a critical part of the pipeline is worth it. Both of your examples are showing a simple type of operation that is easy to support but they aren't general.
Even the simple address modes are really much more complicated: basereg+indexreg*scale+displacement

So to update the base register one would reasonably require going through the address generation stage. Standard updates as in the existing 68k ISA need an incrementer/decrementer.
If the address generation stage takes more than one clock cycle* instructions depending on the updated base register will have to wait, worse, even those that follows (a0)+/-(a0) will** have to wait the extra cycle(s).

Or one could reserve the base register update for the simple disp+basereg address mode only, most likely as fast as executing the increment/decrement versions that have to be supported anyway. That wouldn't be orthogonal but perhaps acceptable?

(* this isn't unheard of, recent Intel processor have an additional cycle of latency for complex address modes, complex here is using more than two inputs)
(** it is possible to fast-path this with extra complications)
Quote:

A longer pipeline is beneficial for increasing FPGA CPU core clock speeds much like a normal CPU. Of course there are major disadvantages to higher clock speeds. There are other ways to increase the IPC which work well in FPGA. Higher clock speeds and a larger L1 DCache would increase the DCache latency and it is more important to keep it low on a CISC "memory munching monster" CPU. I would hope that 2-3 cycle latency would be enough for a 1GHz or lower core. I believe that the single cycle L1 DCache accesses of the 68060 was an important contributor to having one of the best single core performances per MHz of its time.

If everything else is equal a shorter pipeline and low data cache latency is always better.
However that will probably come at the expense of performance in practice - especially when targeting FPGA.
Quote:

I disagree. CISC significantly reduces the memory traffic (including number of accesses while RISC compensates with more registers) and the number of load-use delays (the most common 68k addressing modes have no load-use delay where most RISC CPUs have a load/use delay on every load (requiring more registers to unroll code to try avoiding them). Did I mention that RISC needs more registers and if you run out the cost is much higher? Don't I have enough examples showing all this?

But RISC almost never run out of registers. That they require more registers are per design.
The CISC having to use memory data wastes energy only at best, decreasing performance at the same time at worst.

Every processor have load-use delays. The difference is that a in order CISC with load stages inlined in the execution pipeline (Pentium, 68060, Cyrix 6x86, Apollo) _always_ pays the costs even when not accessing memory. The 68060 compensated for that somewhat by executing some integer operations early reducing the effects (the Pentium did not do that). For RISC the delay is instead exposed and optional.
Quote:

The Apollo core did have 3 in-order superscalar integer pipes at one time but I am not aware of it ever having a dual ported DCache (I suggested a 3rd pipe after looking at average instruction length statistics for 68k code). I told Gunnar a dual ported DCache looked really good and may be necessary to make the 3rd pipe "worthwhile". There would still be only one DCache write per cycle allowed but loads are much more common than stores and would help instruction scheduling of true dependencies instead of making them more difficult to schedule. I could write an instruction scheduler for the 68040+ which includes a hypothetical 3 pipe in-order superscalar core with dual ported DCache. I have been tempted to write a 68060 instruction scheduler for vbcc before but the backend code generation is bad enough that I would just be rescheduling many instructions which should be removed.

2 LD, 1 ST is probably optimal for a standard design. Easiest way to do that would be duplicating the cache so that writes goes to two blocks and each read port connects to a dedicated block.
Didn't know about the third pipeline, guess it decreased maximum clock frequency enough not to be worthwhile in the end?
Quote:

Registers and register files are relatively cheap for a high performance CPU while less so for an energy efficient CPU. Accessing additional registers is considerably more expensive with CISC. I would still like to see a common benchmark which shows an overall performance boost of more than 2% with more integer registers on the 68k before looking for ways to add more registers.

Why would a CISC have expensive register access? Even with my prefix hack the worst case is 50% code expansion. Also register files are much more energy efficient than accessing a cache.

Last edited by megol on 22-Sep-2018 at 09:43 PM.

@wawa

When making real changes to project, I need to be able change, build, test, change build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test, change, build, test…. All day long… can't work be moving files from my PC to test things.

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

@NutsAboutAmiga

its perfectly fine if it suites you well.

but from my perspective:
a) what if your compile crashes the whole build environment while testing, because you test on the same system with shared memory and no protection?
b) even worse, the tested compile corrupts your memory without that you notice leading to random problems you may be unable to trace?

now, what concerns copying files. for what i know michal is using network boot developing native aros for rpi.
myself, im booting x86 either hosted for testing, then i boot x86, ppc and m68k under emulation (qemu or uae) either directly from directory i compile to, or i simply assemble an iso. currently i only copy binaries to cf and boot it with an actual amiga, when it is absolutely necessary to test them with real hardware.

@wawa

a)
a.1) try put lot printf(…) so see what heaped before the system freeze.
a.2) it get too confusing with all debug output, I break code down smaller test cases.
a.3) if bug is random, I take a hard look at memory allocations, and threading in the code, maybe mutex is missing, threads (child tasks) task stop before main task?

b)
This bugs Grim is pretty good at finding,
but sometimes, random crashes is because need to do make clean, because changed some herders, so offsets are wrong. Maybe the memory is freed twice, always null pointers, after they are freed. It helped me so many times.

I mostly write code, I mostly do not port programs, so in most of cases.

1. It worked.
2. It stopped working after some change

So the bug most be in the changed code, or because enabled part of code I did use before, or things might be out of sequence.

Last edited by NutsAboutAmiga on 23-Sep-2018 at 07:25 PM.
Last edited by NutsAboutAmiga on 23-Sep-2018 at 07:17 PM.

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

@NutsAboutAmiga

Compile fast on PC

Use NFS / SMBFS so you can start the executable on your Amiga (AmigaOne or any other NG System) this might be the most convenient way for development.

@NutsAboutAmiga

Quote:

When making real changes to project, I need to be able change, build, test[[...]]…. All day long… can't work be moving files from my PC to test things.

Serious question: Why?

(Asking as someone currently staying in a tiny Italian mountain village, and being paid for developing for hardware attached to my colleague's desktop in Melbourne, Australia. Using the change, build-and-copy, test, repeat cycle All Day (or rather, night) Long. Biggest problem is trying to program the LED user feedback without being able to see the LEDs :)

And especially given that you develop for a system which lacks modern protections, developing on the same system sounds like a Really Bad Idea(tm). Having to reboot, and recreate all the development state from scratch, each time one makes a silly pointer mistake --- sounds painful.

(Disclosure: Amithlon was very much developed on one linux machine, then network-copied to a dedicated test machine, where more often than not it would crash and burn in new and interesting ways. I cannot imagine having to reboot my dev machine each time that happens)

@NutsAboutAmiga

Are you aware bebbo has been working on a nice cross-compiling GCC environment for 68K? (assuming GCC is your thing)

When I get a new 68K environment set up (hopefully this year!!) that is the platform I will be using. An up to date GCC properly optimized for 68K with cross-compiling and remote debugging. :)

https://github.com/bebbo
http://eab.abime.net/showthread.php?t=93055

Cheers!

@gregthecanuck

he is not interested in m68k development for what i know.

and bebbos, while probably best tailored atm, is not the only current crosscompiler with which you can get amiga code. on aros we have 6.3.0 and already experimental 8.1.0.

wawa wrote:

Quote:

he is not interested in m68k development for what i know.

I had to assume that given this thread title

Quote:

and bebbos, while probably best tailored atm, is not the only current crosscompiler with which you can get amiga code. on aros we have 6.3.0 and already experimental 8.1.0.

If you want 68K code bebbo's is the best. He has implemented a number of optimizations. Wilen's pfs3aio uses this compiler as of version 3.0... getting smaller (16K smaller!) and better code.

The more options the merrier

Real 68k is too slow to be usable.
There is no fun in making software for real 68k.
68k users should not expect amiga developers to optimize software for 68k amiga.
You want to use slow 68k Amiga? It is your choice and your problem.

@ppcamiga1: then completely disable 68K emulation on your OS4 setup, and be sure to do not use tools like RunInUAE.

I assume that you use ONLY PowerPC binaries, right? No need at all to use "slow 68K" applications.

@bison

Quote:

bison wrote: @cdimauro Quote: The Cortex-A53 is quite old and not so much efficient. It has been superseded by the Cortex-A55, I think, although I don't know of any mainstream products that use it. Perhaps the Pi4 will.

There are also A72 and A73. Unfortunately I've found no data about what we discussed.

@matthey, @hth313, and to who's interested on code density topic:
RISC-V ISA: Understanding Limitations and Methods to Improve Code Density & Performance
https://www.youtube.com/watch?v=0oyTaCC8qQs

@ppcamiga1

you know how fun it is to make software for real 68k?

What software exactly have you written anywhere?

Quote:

You have to become a verifed forum user to continue posting. Some of your posts did not match our forum usage rules. Unfortunately some people misuse the annonymity of the internet to insult people. To verify that you are a genuine person we kindly ask you to email as a proof of your identity. Please email us a copy of your ID card or driving license or similar to info@natami.net. As soon as we recieve they proove of your identity you will be able to fully use the forum again.

Rotfl for several minutes.
Gunnar has your number, warned you and kicked you off, with the proviso that if you would like to come back, he will have your ID, and can report you to the authorities for online harrasment/abuse/whatever un law has been breached.
Rotfl.
Gunnar proved on his forum, and indeed you have backed up with evidence that you have freely provided, that Gunnar doesn't take shit and pwned you.
He is to be congratulated at his dealing with improper conduct.of which I witnessed you committjng on the Apollo forum.
Bravo Gunnar.

_________________
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

I serve King Jesus.
What/who do you serve?

@OlafS25

What I want to know, is there anyone going to lend a hand to the netsurf team to have it polished for the vamp. Maybe even a saga version?
Reasonable browsing on an a500 ( mobile sites are OK by me).

_________________
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

I serve King Jesus.
What/who do you serve?

@Barana

And also he has shown great graciousness in leaving the door open if you'd wish to come back.
It takes a bloke with balls to do that.
Gunnar has played the man here.
Have YOU got the balls to treat him with the same grace an courtesy he has treated you with, as evidenced in your post about the login message you offered to us?

Offensive remark removed - _Steve_

But the way Gunnar has been so gracious to you,has me gobsmacked.

Last edited by _Steve_ on 30-Sep-2018 at 06:20 PM.
Last edited by Barana on 24-Sep-2018 at 12:14 PM.

_________________
Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

I serve King Jesus.
What/who do you serve?

@cdimauro

I use 68k appliactions on my NG Amiga. works better on my NG Amiga than on real 68k hardware.

Last edited by ppcamiga1 on 24-Sep-2018 at 05:44 PM.

@Barana
Disgusting.