Why not create a "CISC-V", open like RISC-V? It could be based on 68060 as a starting point.

_________________

@NutsAboutAmiga

Quote:

The difference between Basic and (C or Pascal) is that C and Pascal does not do house cleaning, you need allocate memory, open windows, close windows and so on, and you as programer who need to make sure the memory or object is freed, when the program exist, or else you get a memory leak.

That must be an Amiga thing. On Linux, the kernel will free any memory a program fails to free after it exits. In fact, it won't even allocate the memory when malloc is called -- it waits until the memory is accessed. The only way you can have a memory leak is when a program is running (which can be a problem with long-running server programs). I expect Windows and macOS have similar behavior.

Update:

I misread your post. I thought you said "when the program exits," but what you really said was "when the programs exist," by which I assume you mean, while it is still running. Sorry for the confusion.

Last edited by bison on 15-Dec-2018 at 07:20 PM.
Last edited by bison on 15-Dec-2018 at 07:19 PM.
Last edited by bison on 15-Dec-2018 at 06:50 PM.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bison

You have memory leaks on Linux too, it's not uncommon to have reboot script in cron, if your running apps 24/7.

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

@NutsAboutAmiga

Yes, but... that was my point.

_________________
"Unix is supposed to fix that." -- Jay Miner

@WolfToTheMoon Quote:

WolfToTheMoon wrote: Why not create a "CISC-V", open like RISC-V? It could be based on 68060 as a starting point.

It could be certainly possible, but RISC-V was an ISA completely written from scratch, without any constraint, so the designers were able to freely take every decision that they made.

Here you suggest that such "CISC-V" should be "based on 68060": how?

Binary compatible -> You're carrying on all mistakes that Motorola did with this ISA.

Source compatible -> You can remove most of the mistakes, but still has to keep & maintain some.

Inspired -> You can keep the good 68K ideas, removing all legacy stuff / mistakes, and provide also some partial source-level compatibility.

The ISA that I've developed (which I've called NEx64T, albeit CISC-V could be a good marketing term ) is inspired by 68K and x86/x64, albeit I had the chance to keep 100% source-level compatibility with the later (but almost all legacy stuff is substantially gone, and the few things left are considered deprecated).
That's because I wanted to have "free hands" to express and implement my ideas about a novel CISC design.
x86/x64 source-level compatibility was just a coincidence (my first idea was to just give a successor to them, like what I did with the 68K before, but without imposing any strict compatibility), which I decided to keep only because the cost was very very little, while the advantage is HUGE (almost all x86/x64 applications can be just recompiled for it).

Coincidentally, I started working on my ISA at the same time that the Berkeley guys started the RISC-V project, and reached similar goals albeit with a very different design and philosophy: a state of the art CISC ISA.

NEx64T was made starting from my previous work, when I've realized an 68K inspired 64-bit ISA, like I said before. Now, with the experience accumulated with the last ISA, I'm thinking about designing another 68K-inspired one, which is more strongly founded on Motorola's first design (simple and compact ISA, but this time with a NET separation between data and address registers to better exploit this concept, and maybe introduce another 8 data registers).

Quote:

WolfToTheMoon wrote: Why not create a "CISC-V", open like RISC-V? It could be based on 68060 as a starting point.

RISC-V is the 5th Berkeley RISC design. SPARC is the closest commercial adaption of early Berkeley RISC designs.

1) RISC-I (Gold)
2) RISC-II (Blue)
3) RISC-III (SOAR)
4) RISC-IV (SPUR)
5) RISC-V

https://en.wikipedia.org/wiki/Berkeley_RISC

The wiki page above has the following biased statement.

"Program size was about 30% larger than the VAX but very close to that of the Z8000, validating the argument that the higher code density of CISC designs was not actually all that impressive in reality."

RISC fans like to compare to weak code density competition, cherry pic results, compare overall program size instead of code density, etc. as some RISC-V literature does the same. SPARC code density is likely 45%-55% worse than the 68k or Thumb2. The Berkeley RISC-V designers seem to finally recognize that code density is important though.

"The initial RISC ISAs from the 1980s all picked performance over code size, which was reasonable for a workstation environment, but not for embedded designs. Hence, both ARM and MIPS subsequently made versions of the ISAs that offered smaller code size by offering an alternative 16-bit wide instruction set instead of the standard 32-bit wide instructions. ARM Thumb and MIPS16 have only 16-bit instructions, while later Thumb2 and MIPS16e/microMIPS variants offer both 16-bit and 32-bit instructions.

Compressed ISAs reduced code size relative to their starting points by about 25-30%, yielding code that was significantly smaller than 80x86. This result surprised some, as their intuition was that the variable-length CISC ISA should be smaller than RISC ISAs that offered only 16-bit and 32-bit formats.

...

Leveraging 25 years of hindsight, RISC-V was designed to support compressed instructions from the start, leaving enough opcode space for RVC and many other extensions. As all compressed instructions are variations of RVI instructions|which must be included in every RISC-V implementation|the optional compressed instructions are compatible with all current and future RISC-V extensions. Thus, RV32C, RV64C, and RV128C are all valid, as would be RV32GQLCBTP.

The philosophy of RVC is to reduce code size for embedded applications and to improve performance and energy-efficiency for all applications due to fewer misses in the instruction cache. Waterman shows that RVC fetches 25%-30% fewer instruction bits, which reduces instruction cache misses by 20%-25%, or roughly the same performance impact as doubling the instruction cache size."

https://riscv.org/wp-content/uploads/2015/05/riscv-compressed-spec-v1.7.pdf

RISC-V favorably compares some of the best compressed RISC code density (Thumb2) to that of the 80x86 even though its RVC is closer in coded density to that of the 80x86. We saw a later paper on code density and instruction counts where Thumb2 was also conveniently excluded. RISC-V compressed is a big improvement in code density from older RISC architectures but only goes a little more than half way to good code density architectures. We can see from the last paragraph of the quote above that every 25%-30% improvement in code density allows to half the instruction cache and the difference in code density from worst to best architectures is about 50% so an 8kiB ICache can have close to the same performance as a 32kiB ICache on the worst code density architectures (nice savings on a multi-core CPU). Some people suggest this doesn't matter although most of the worst code density architectures are dead or dying now (Alpha, PA-RISC, MIPS, SPARC, PPC). PPC code density is actually a little better than the rest but likely 40%-50% worse than the 68k and the 68k has room for code density improving enhancements and compiler improvements. The 68k provides this code density without high instruction counts or memory traffic unlike most compressed RISC formats. The choice of architectures seems to be more about marketing, popularity and hype than looking at the numbers though.