A mathematical demo

[matthey]

Originally Posted by NorthWay

I just recently read a paper on the RISC-V (https://people.eecs.berkeley.edu/~kr...ECS-2016-1.pdf) which has been designed with compression in mind. They discussed (among others) x86 and x64 code size and found it was rather much larger (IMO) than conventional wisdom claims. 68K was not mentioned, but I'm guessing it would begin to look good in that regard.

Yea, the author practically makes fun of the x86 (IA-32) and x86_64 ISA deficiencies. The x86 code density can vary substantially depending on the datatypes used (good with byte sizes primarily) and size of the executable. Complex functions and their arguments can make it abuse the stack and reduce code density where it only has 8 registers and an ABI which passes args on the stack. The 68k has better code density with a wider range of datatypes (good with sign extended immediates) and up to a medium sized executable size. Register spills are less common with more registers but the AT&T ABI is still used to pass args on the stack. Also, any ISA code density advantage falls apart when compilers don't do their job. I already new that the x86_64 ISA is nothing special when it comes to code density. Just look at the cache sizes necessary to make a modern x86_64 CPU fast. All 64 bit processors are going to need considerably larger DCache sizes to go with those fat ICaches too. The 8 bit base encoding of the x86 and x86_64 causes new instructions to be longer making code density worse and decoding slower which offsets some of the advantages of any new functionality. This is not true of the much better 16 bit base encoding of the 68k where new instructions can improve code density at the same time as improving functionality. This is true because the 16 bit encoding was wide enough to leave room for future encodings where 8 bit was not.

RISC-V starting with (an optional) code compression is an improvement over most of the RISC compression methods which need new modes like Thumb 2 and SPARC16. These RISC compression methods may give better code density but is it worth the trade off of fewer available registers (usually 8) and reduced instructions and functionality requiring more instructions and more cache/memory accesses? They give many of the handicaps of the original x86 ISA and with increased complexity from multiple modes. Amazingly, even with all these handicaps of the compressed ISAs, they still commonly provide a performance boost and power consumption savings (RISC lack of code density is that much of a handicap). RV32C (RISC-V 32 bit ISA with code compression) avoids most of the problems as the 32 bit encodings can be used when needed and the more efficient and common 16 bit encodings when possible. This always gives better performance both because of less ICache misses and because using the RV32C compression gives a performance boost by bringing PC relative branches into the rather limited range of the RISC-V branch instruction (RISC-V is a simplistic and spartan ISA). So why not use the compression all the time instead of making it optional? Some embedded processors may need a simple and small CPU and they use only small code where code density doesn't matter. Sure, but by having it optional, you have duplicate functionality and wasted encoding space when the compression is used (there is always a 32 bit equivalent of every 16 bit instruction). Now if you took away the duplicate functionality which wastes encoding space you would have a 16 bit base variable length encoding which resembles and has the efficiency of a well encoded 16 bit variable length encoded CISC CPU. Ok, the 68k isn't the most efficiently encoded 16 bit variable length ISA but I bet it is still good enough to beat the RV32C in code density .

The biggest advantage I see of RISC-V is the open and extendable ISA which leaves plenty of customizable encoding space free (the free space does reduce the code density but still beats most other RISC ISAs). I expect it will be limited to embedded uses with too many incompatible custom variations (like ARMv7) to build a useful software base. Ironically, the author complained about ARMv8 standardizing their ISA too much and not allowing customizations. RISC-V is too simplistic with too many options while ARMv8 is too robust (fat) with out enough customizability. I would expect ARM to have the edge in the battle because it has a name in embedded "power efficient" processors even though ARMv8 processors are likely to be much less power efficient with the ARMv8 ISA. It is interesting that the PPC has fallen so far that it was not even listed in the benchmarks. I guess it is becoming difficult to find a PPC for testing without paying 10x what a PC costs. RIP PPC.

Originally Posted by NorthWay

(My only complaints against the RISC-V would be that it has no big<->little endian instructions or loads/stores, and no load/store multiple.)

Well, it is open and customizable but at the expense of standardization. I suppose it would be possible to create a standard ISA extension(s) for the base RISC-V ISA but it would take a big name to do it and most big businesses want to make their ISA proprietary. A standardized ISA allows economies of scale to produce cheaper processors but then the competition can also buy those processors. It would be great if a bunch of savvy smaller businesses would adopt good standards which would allow them to compete with the big boys but then if they were that smart they would probably already be a big boy .

[litwr]

I've just got a report that my programs work wrong with A500 with 68010, 2meg chip and 8meg fast. It skips timer and gives always about 8 sec. for 3000 digits - it should be more than 150 sec. The standard A500, A1200, even A4000 work fine with pi-spigot... What can cause the issue? Any suggestions?
http://www.amibay.com/showthread.php...-run-it-for-me!
http://eab.abime.net/showthread.php?t=82392
BTW Is it exactly known how AllocMem works? What kind of memory it try to allocate at first fast or chip? Thanks in advance.

[hooverphonique]

Originally Posted by litwr

BTW Is it exactly known how AllocMem works? What kind of memory it try to allocate at first fast or chip? Thanks in advance.

AllocMem allocates the first available memory it finds that satisfies the specified flags, but takes the priority of the memory list into account. Normally, fastmem should have higher priority than chip, but that's entirely up to the code that binds the memory into the OS memory list.

I think older kickstarts (1.2) have an issue where they don't bind fake fast at a higher pri than chip, which means you could get chip where you wouldn't expect it.

[litwr]

Thank you. Is there a way to load program from CLI directly into the fast memory?

[Samurai_Crow]

If the memory hunks in the program specifically are marked to load into Fast RAM, they will. Usually those hunks are marked for any RAM so it would be able to load into Chip RAM if there is no Fast RAM.

[matthey]

Originally Posted by litwr

Thank you. Is there a way to load program from CLI directly into the fast memory?

Yes, by specifying a fast memory flag in the section statement. This adds the flag to the hunk corresponding to the section statement. This will also cause the program to fail on Amigas without fast memory so I don't recommend it.

[litwr]

A lot of thanks for help.

Originally Posted by matthey

Yes, by specifying a fast memory flag in the section statement. This adds the flag to the hunk corresponding to the section statement. This will also cause the program to fail on Amigas without fast memory so I don't recommend it.

Excuse me I missed a lot with Amigas. How exactly could it be made? What command to use? etc

[Samurai_Crow]

The memory flags are part of the program you are running. It is not a CLI command.

[matthey]

Originally Posted by litwr

Excuse me I am missed a lot with Amigas. How exactly could it be made? What command to use? etc

The section statement may vary some depending on your assembler. Motorola syntax will usually use something like the following.

Originally Posted by vasm manual

section [<name>,]<sec_type>[,<mem_type>]

Starts a new section named <name> or reactivates an old one. <sec_type> defines the section type and may be code, text (same as code), data or bss. <sec_type> defaults to code in Phxass mode. Otherwise a single argument will start a section with the type and name of <sec_type>. When <mem_type> is given it defines a 32-bit memory attribute, which defines where to load the section. <mem_type> is either a numerical constant or one of the keywords chip (for Chip-RAM) or fast (for Fast-RAM). Optionally it is also possible to attach the suffix _C, _F or _P to the <sec_type> argument for defining the memory type. The memory attributes are currently only used in the hunk-format output module.

http://sun.hasenbraten.de/vasm/

[litwr]

Thanks. It looks not easy but I am going to try. I am curious how much faster becomes pi-spigot with A500/1200 using fast RAM? Any estimation? 10% boost makes again 68020 faster than 80386.

[matthey]

Originally Posted by litwr

Thanks. It looks not easy but I am going to try. I am curious how much faster becomes pi-spigot with A500/1200 using fast RAM? Any estimation?

The fastest memory will usually be used first if no memory flags are specified. MEMF_ANY is the default memory allocation flag which allocates the highest priority (usually fastest) memory first. This is optimum and should not be messed with except for test purposes (and possibly avoiding bugs in ancient versions of the AmigaOS).

http://amigadev.elowar.com/read/ADCD.../node02A8.html

Adding fast memory to an Amiga without it will make a big difference in performance. It can double the performance depending on many factors. Compare a stock Amiga 1200 to one with a fast memory expansion here.

http://amiga.resource.cx/perf/aibb.p...name&ref=a1200

[litwr]

Thank you very much for this valuable information. The results for Blizzard 1200, Bio-Con 1208MA, DKB 1202, ... show that 68020 is much faster than 80386. Amiga with chip RAM only reminds me another Commodore. Commodore +4 uses normally only 63% of its CPU power but it may use almost 100% of it with screen off mode. Is it possible to do the same trick with Amiga? To disable video and gain more speed?
I'm also curious do Macintosh II or LC utilize 68020 power so poor as the base Amiga 1200? There is the same question for Atari 68030 based systems...

[Samurai_Crow]

Disabling the display DMA is possible but I think dropping the screenmode to 3 bitplanes may speed up enough to do lots of good already.

[kovacm]

Originally Posted by litwr

I'm also curious do Macintosh II or LC utilize 68020 power so poor as the base Amiga 1200? There is the same question for Atari 68030 based systems...

I have both: Mac LC II and Atari Falcon030... [ Show youtube player ]

[nogginthenog]

Originally Posted by litwr

Commodore +4 uses normally only 63% of its CPU power but it may use almost 100% of it with screen off mode. Is it possible to do the same trick with Amiga? To disable video and gain more speed?

Yes, because the 680x0 and custom chips both have to share chip ram bandwidth and the custom chips have priority.

Graphics card users can set a switch that disables native video when not in use.

[litwr]

Originally Posted by kovacm

I have both: Mac LC II and Atari Falcon030...

Thanks for this interesting video. Atari ST series was good but had a kind of bad karma. They always looked for me like shadows of Amiga. However Commodore weakly promoted Amiga too, too slow upgraded them, ...

[kovacm]

Originally Posted by litwr

Thanks for this interesting video. Atari ST series was good but had a kind of bad karma. They always looked for me like shadows of Amiga. However Commodore weakly promoted Amiga too, too slow upgraded them, ...

Well no hard feelings: Amiga always look like gaming machine to me.
Ridiculous RGB monitors unsuitable for any long time work while with ST and Aladin you get full Mac emulator back in 1986/7.

[litwr]

Originally Posted by kovacm

Ridiculous RGB monitors unsuitable for any long time work while with ST and Aladin you get full Mac emulator back in 1986/7.

I had to use a cheap bw monitor for texts or a cheap composite monitor for games with my A500.
BTW Excuse me a slightly ignoramus question but I am curios for it for about 25 years. Why fast RAM was so rare? Did it require more expensive RAM chips? More special circuits? I failed with fast RAM even with FS-UAE. The emulated A500 with fast RAM shows the same speed with my demo as without fast memory at all, indeed, I clicked on FastMemFirst icon at first. The emulated A1200 doesn't even show the presence of fast RAM. I use 'fast_ram = 2048' configuration option. Could anybody provide any explanations to these facts? Please help.
EDIT. Sorry, I had an error. I had to use 'fast_memory' instead of 'fast_ram'. So the last question is closed.
EDIT. I made some successful tests with FS-UAE emulator with fast RAM. They show that fast RAM gives about 9% speed boost for A1200 and only 2% for A500. It is much less than the expected 100%. However A1200 with fast RAM becomes slightly faster than 386DX @12.5 MHz - http://litwr2.atspace.eu/pi/pi-spigot-benchmark.html

[idrougge]

If fast RAM gives such a small boost, your code isn't very RAM-intensive.

[litwr]

Originally Posted by kovacm

Well no hard feelings: Amiga always look like gaming machine to me.
Ridiculous RGB monitors unsuitable for any long time work while with ST and Aladin you get full Mac emulator back in 1986/7.

Amiga 500 has a lot of productivity software, good support for C, ... I remember Mac emulator for A500 but I couldn't use it.

Originally Posted by idrougge

If fast RAM gives such a small boost, your code isn't very RAM-intensive.

It is a quite standard integer math calculation with an array. I assume that a program placed to fast RAM should be faster than a program in chip RAM.