Quote:

pgf_666 wrote: High code density is nice, but it isn't the holy grail. For me. that grail is performance, and ease of use. I want something that gives me the equivalent of a 68060 running at 32 GHz (8 cores at 4 GHz should be close enough), great graphics, of course (otherwise I'd be on a different board), and the ability to run my 32-bit apps at native speed, with full integration; that's why I haven't switched to the 64 bit version of ARos!

Code density affects performance and energy efficiency. A 68k CPU can have 50% more code in the instruction cache (ICache) than a PPC CPU with similar sized instruction cache. If the code is not in the ICache then it must be reloaded from slower caches or memory before GHz execution can continue and may have to share bandwidth with data accesses (including in other cores). Making caches larger slows them down as electricity takes longer to propagate across a longer distance. Code density is not the holy grail for performance but there are limited ways which modern CPUs can improve performance with Moore's law ending. ISAs with good code density have an advantage over those which do not and we are seeing modern ISAs becoming more competitive in this regard as a result.

A 4 GHz 68k core would be expensive to design and require a state of the art die process. It would be too risky to invest the amount of money required in an uncertain market. A 16 core 2 GHz or 32 core 1 GHz 68k would be much cheaper to produce.

It is possible to maintain 32 bit compatibility on a 64 bit CPU at the same time with modes. Most ARM AArch64 CPUs allow this while x86_64 CPUs require booting into 32 bit or 64 bit mode. A 64 bit 68k CPU could use modes like ARM. It is also possible to allow 64 bit operations like the Apollo Core uses without a 32 bit compatibility mode but this has disadvantages as well.

Quote:

The O/S is important , of course, but 3.9+ with a couple of tweaks should do it--expand the memory map to 64 bit addressing, etc.

It is easy to add 64 bit addressing to the CPU but not as simple to support it in the AmigaOS. AmigaOS structures use 32 bit pointers which now need to be 64 bits. If it was easy to add and maintain compatibility then AmigaOS 4 would have done it for their 64 bit PPC CPUs. PPC does not have a simultaneous 32 bit mode for compatibility like ARM though.

Quote:

I do virtually ALL my personal programming--including some stuff for the Win-Don't environment!--in UAE, because it's easier, and sometimes even faster...._Yeah, I know, sick,isn't it?)

The AmigaOS is very responsive for editing but compiling on a single core CPU is painful.

Quote:

And if the registry files gets a bit big--have you SEEN the size of modern chips, and figured out how many 68060s you could put on them at current best fir sizes?

Semi-modern desktop CPUs are roughly 1,000,000,000 transistors (4-8 cores). The 68060 was 2,500,000 transistors so a multi-core 68060 CPU could have 400 cores on the same sized die.

Last edited by matthey on 11-Dec-2018 at 05:15 PM.

@matthey

Originally, the 68060 was produced in 0.6 μm and later 0.42 μm process. I would target porting the CPU onto something like 0.18 or 0.13 process, which would be alot cheaper then newer, smaller nodes. Cost goes up after 65 nm, IIRC.

_________________

Quote:

WolfToTheMoon wrote: Originally, the 68060 was produced in 0.6 μm and later 0.42 μm process. I would target porting the CPU onto something like 0.18 or 0.13 process, which would be alot cheaper then newer, smaller nodes. Cost goes up after 65 nm, IIRC.

Yes. It would make sense to start with old die sizes for an ASIC. It is possible to produce TCP/IP stack capable CPUs for about $.03 U.S. each using underutilized fabs. Large production quantities are needed which can be achieved by sharing production with embedded partners (I had good luck finding 68k friendly potential embedded partners). I wrote about the costs and details of an ASIC in the following thread.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=42886&forum=17&3#817558

@matthey

You could always share a waffer with other chips. Some foundries offer that option for lower volume production and/or testing and prototypeing.

But one should first do a proper survey of the market - where are 68K chips still used, where is the biggest chance to attract customers and such.

_________________

Quote:

WolfToTheMoon wrote: You could always share a waffer with other chips. Some foundries offer that option for lower volume production and/or testing and prototypeing.

Sure.

Quote:

But one should first do a proper survey of the market - where are 68K chips still used, where is the biggest chance to attract customers and such.

The 68k is mostly used in old and niche embedded CPUs (rare to find today). It was the most popular 32 bit embedded CPU in the '90s and embedded developers still remember it fondly. No embedded 68k CPU surpassed the performance of the 68060 and ColdFire CPUs did so with only significantly higher clock speeds. With low performance and out of date SoC features, Motorola/Freescale/NXP was successful in killing the dominant 68k embedded market and handing it to ARM Holdings.

One embedded partner producing CPUs in the millions would be enough to make per unit production costs low. I had productive conversations from approaching a few embedded businesses with 68k connections. However, businesses expect professional products today or they would be better off with ARM even though they prefer the 68k.

@matthey: the main problem is that now there's RISC-V as the big contender. It'll leave less and less space in the embedded world, and erode A LOT of ARM market.

Another big problem is that 68K should be in some way cleaned-up / enhanced / modernized (no, I'm not talking about SIMD now), especially giving a 64-bit (the next frontier, even in the embedded world).

BTW, x86/x64 can switch back and forth between real -> protected 16/32 bit -> 64-bit long mode. You're not forced to stay on protected mode once you're there. If you have an o.s. running, then yes: you're locked there, but the same happens on other ISAs (ARM included).
The good thing of ARM is that it has some "special execution modes" in 32-bit mode, like Thumb1/-2, ThumbEE, Jazille, where you can switch back and forth without leaving the 32-bit execution mode.

@pgf_666: code density is very important, as matthey already pointed-out. AFAIR there was a study (unfortunately I don't find it anymore) reporting that a 25% INcrease (NOT decrease; sorry. EDITED) in code density means that you can HALVE the L1 code cache!

That's the reason why many ISAs, even RISC ones, provided some "compact ISA" execution mode or short instructions, to have a better code density.

However an ISA should not be exclusively "code density-oriented": a good balance of all features might be a better solution.

Last edited by cdimauro on 13-Dec-2018 at 05:47 AM.

@everyone

I'm not sure if youse-guys are getting my point, so, let's start with the very basics:

1: A synonym for "User" is "Customer". No matter how brilliant it is, if they don't buy it, you're left holding a bag of fairlay expensive silicon.

1a: This means finding out what the customer wants, or at least, what you can sell him, then building it--and selling it! The 65832 was marvelous, ran AppleII and Atari800XE stuff wonderfully fast, but the general computer buying public wasn't even aware of it as an alternative to the 68000 or 8088.

2: Software support is mandatory. At the very least, 3,10 needs ti handle multiple processors like it does multiple tasks--so that old 68k multi-tasking software can just run as usual, and let the O/S handle the details--after all, that's what it's there for. Also, if you're going for the retro market, make sure ST/TT systems can handle it, as well as 68K Nac systems--include multi-processing patches to the various O/Ss if need be.

3: It's fine to produce a separate chip for the embedded--or any other-market if the market will support it; Mt produced the 68050, for instance, for just that reason

4: Note that my mother was raised in England; a British "nice" is about equivalent to a Yank "Way Cool"...

5: There should be easy to read/use docs--while the RKM is far from the worst documentation I've seen--I read the original WordStar manual!--it falls flat on its face for someone trying to program BASIC, and, frankly, BASIC--HiSoft BASIC II, usually--is my language of choice. I can put a dot on a screen with a single line of code--let's see you do that in C or Pascal!

6: There is no point 6

7: I think the issues with the o/s and user programming languages each deserve their own thread; I'll try to start them tonight.

8: Thanks all for the serious responses, and have a Merry XMas, Chapp0y Chabucha, Happy New Year, and/or whatever else may apply!

@matthey

I can argue that 1 bit processor can have as many as 32 instructions, compared to a 32bit CPU that can only have 1 instruction, and there for the 1 bit processor has better code density then 32 bit CPU.

I find the argument about code density to be silly at best,

just looking up the 68060 cpu.

https://en.wikipedia.org/wiki/Motorola_68060
• 8 KB DCache (4-way associative)
• 8 KB ICache (4-way associative)
• 96 byte FIFO Instruction Buffer
• 256 Entry Branch Cache
• 64 Entry ATC* MMU Buffer (4-way associative)

It has (8*1024)+(8+1024)+96+256+64 = 16800 bytes / 16.4 Kbytes of cache.

PowerPC PA6T has
L1 cache
64+64 KB/core
L2 cache
2 MB/core

One core in PA67T has 4 times the cache size of 68060,

http://cache.freescale.com/files/32bit/doc/data_sheet/MPC7455EC.pdf

the PowerPC 7455 (G4)
has 32 Kbyte Cache, so it has 2 x the cache size of 68060.

So yes the instructions might take more space, but cache size is also bigger, unless your only calculation with only number of +/-32,768, or 65,535, a real 32bit CPU is better.

Not to consider the fact that PA6T has two cores with 64K cache, and can do twice the work load. Even with considering things like altivec, out of order execution and so on.

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

@pgf_666

Quote:

I can put a dot on a screen with a single line of code--let's see you do that in C or Pascal!

Yes it take only one line in Pascal or C,
in Pacal writing to VGA video memory you can do (only works on PC, sorry I have worked with Pascal in years):

mem[$A000: y*320+x]:=c

Writing into rastport (window) on AmigaOS, WritePixel uses current color.

WritePixel(window -> RastPort, x,y);

There is WritePixelColor, I think this one requiere AmigaOS4.x, but maybe I'm wrong.

WritePixelColor(window -> RPort, x,y, 0xFF0000);

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. C++ or C# is bit more forgiving if you write constructors and deconstructors.

as for 68080 does require that you write in 680x0 Assembler to use new features, and not C/Pascal.

Last edited by NutsAboutAmiga on 13-Dec-2018 at 02:35 PM.
Last edited by NutsAboutAmiga on 13-Dec-2018 at 02:28 PM.

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

@NutsAboutAmiga

Quote:

I find the argument about code density to be silly at best

It's not silly if you have a transistor and/or power budget - in the embedded world that's often the case.

PA6T is a piece of s*** CPU even with 40 times the cache of 68060, evident by the fact that almost no one used it for anything.

Last edited by _Steve_ on 25-Dec-2018 at 12:38 PM.

_________________

@WolfToTheMoon

Apple switched to Intel, the chip ended up being most just used by US military. Not the CPU's fault, that its not used a lot, its lot less power Hungary then a G5. AmigaONE-X1000 production stopped due price of the chips went up, after Apple bought PA Semi, and closed the doors on it. arguably the QorIQ 5020 and 5040 is lot faster then PA Semi, but the QorIQ cpu's are many years newer design. Power 9 is really out our price point.

(not talking about AltiVec that 5020 don't have.)

Last edited by NutsAboutAmiga on 13-Dec-2018 at 02:46 PM.
Last edited by NutsAboutAmiga on 13-Dec-2018 at 02:43 PM.

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

Quote:

cdimauro wrote: @matthey: the main problem is that now there's RISC-V as the big contender. It'll leave less and less space in the embedded world, and erode A LOT of ARM market.

RISC-V has competitive code density for RISC and is an open ISA which is appealing and competitive. They are doing many things right as far as development but the ISA has drawbacks too. It is simplistic, lacks personality and has too many variations. There are developers who don't like it. More choices are good. There used to be more embedded choices but the number of ISAs has shrunk as the market has exploded.

Quote:

Another big problem is that 68K should be in some way cleaned-up / enhanced / modernized (no, I'm not talking about SIMD now), especially giving a 64-bit (the next frontier, even in the embedded world).

I agree. The 68k needs development and modernization. I was assuming enhancement of course.

Quote:

BTW, x86/x64 can switch back and forth between real -> protected 16/32 bit -> 64-bit long mode. You're not forced to stay on protected mode once you're there. If you have an o.s. running, then yes: you're locked there, but the same happens on other ISAs (ARM included). The good thing of ARM is that it has some "special execution modes" in 32-bit mode, like Thumb1/-2, ThumbEE, Jazille, where you can switch back and forth without leaving the 32-bit execution mode.

An important part of the question I answered was about compatibility. It should be possible for an enhanced 68k CPU and AmigaOS to allow 64 bit and 32 bit applications to execute simultaneously using different modes. Perhaps this could provide better compatibility but also may cause too much complexity in the AmigaOS. Simultaneous 64 bit and 32 bit modes are not a problem for a CPU.

@pgf_666
I want Amigas which are easy to use, fun to use, affordable, compatible, developed and supported too. I believe this is only possible with mass production.

Quote:

NutsAboutAmiga wrote: One core in PA67T has 4 times the cache size of 68060,

Larger caches per core use more transistors resulting in fewer cores or more die area used which adds to production costs. This also results in higher idle energy use and a longer latency to access the cache (probably at least 3 cycles to access L1 caches where the 68060 is 1 cycle). The primary reason multi-level caches were created was to avoid the latency increase of larger caches. Improving code density increases the amount of code in the ICache instead of enlarging the caches. This can slow the decoder and pipeline but can be cheaper than enlarging the caches. There are no free lunches in CPU design.

@matthey
The most reasonable way to get a large enough market is probably making a processor optimized FPGA. Hardware blocks for caches, register files, ALUs/shifters/multipliers/dividers etc. with enough programmability to implement most types of processors. Not as fast as a dedicated processor of course but should give a huge advantage over a standard FPGA.

Edit: Semi-related semi-OT but perhaps someone interested in 68k have an answer.
According to the Apollo wiki both FADD and FMUL take one cycle which is incredibly fast if true. In comparison I've calculated using >5 pipeline stages to do an extended precision FMUL with proper rounding, but even if some of that is due to targeting higher frequencies how could one do this in one cycle? Wondering if it is a placeholder value or if they are doing something really clever.

Last edited by megol on 14-Dec-2018 at 06:30 PM.

@NutsAboutAmiga

Quote:

AmigaONE-X1000 production stopped due price of the chips went up, after Apple bought PA Semi, and closed the doors on it.

Apple bought (and closed) PASemi years before Trevor had his(?) brainfart of using the P6T for the X1000.

Only chips ever available were NOS earmarked for (replacements in) military projects when the contracted holding time for these went out they became available.

Wether Trevor overestimated the supply, underestimated the demand for the X1000 or just hadn't thought about prices going up............

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

Quote:

megol wrote: The most reasonable way to get a large enough market is probably making a processor optimized FPGA. Hardware blocks for caches, register files, ALUs/shifters/multipliers/dividers etc. with enough programmability to implement most types of processors. Not as fast as a dedicated processor of course but should give a huge advantage over a standard FPGA.

A specialized FPGA may be the answer for increasing performance but not for lowering cost. FPGA production also benefits from economies of scale making generic FPGAs cheaper than specialized ones. An ASIC could lower per unit costs as well as increase performance *if* production was high enough. The competition using mass produced ASICs/CPUs will always have a competitive cost advantage over someone paying for FPGA CPUs/SoCs. ARM CPUs are so cheap because they are mass produced for embedded applications and not because of any inherent advantage of the architecture. They did have an advantage of a small die size for low end CPUs but this goes away with higher performance CPUs where more caches and OoO are needed for RISC.

Quote:

Edit: Semi-related semi-OT but perhaps someone interested in 68k have an answer. According to the Apollo wiki both FADD and FMUL take one cycle which is incredibly fast if true. In comparison I've calculated using >5 pipeline stages to do an extended precision FMUL with proper rounding, but even if some of that is due to targeting higher frequencies how could one do this in one cycle? Wondering if it is a placeholder value or if they are doing something really clever.

The cycle times are throughput cycles instead of latency cycles. Every cycle one FMUL can finish but the latency is several cycles. Think of a production line where a product takes 5 hours to complete. Each hour a new unit is started until the pipeline is full. Each hour a new unit is completed (1 hour throughput) but each unit still requires 5 hours of work (5 hour latency). The latency can be exposed by a delay somewhere in the pipeline (mis-predicted branch or load delay/bubbles for a CPU).

@pgf_666 Quote:

pgf_666 wrote: @everyone I'm not sure if youse-guys are getting my point, so, let's start with the very basics: 1: A synonym for "User" is "Customer". No matter how brilliant it is, if they don't buy it, you're left holding a bag of fairlay expensive silicon. 1a: This means finding out what the customer wants, or at least, what you can sell him, then building it--and selling it!

There's also the opposite, obvious, problem: without a product there can be no customers that purchase it.
Quote:

The 65832 was marvelous, ran AppleII and Atari800XE stuff wonderfully fast, but the general computer buying public wasn't even aware of it as an alternative to the 68000 or 8088.

Maybe because it wasn't really "marvelous"? 65832 sucks as well as its predecessor, the 65861. The only advantage is that they can replace a 6502, but the architecture itself is an HORRIBLE patch over the 8-bit one.

Sometimes it's better to kill an ISA, instead of giving bad successors.

Yes, I'm talking about 8086 as well here: no exceptions. It was a good successor for the 8085 (it was almost completely source-level compatible, while giving a 16-bit "extension": this was the best thing to do), considered the time when it was released, but 8086 successors were bad patches over this ISA, instead of re-thinking/re-writing it.
Quote:

2: Software support is mandatory. At the very least, 3,10 needs ti handle multiple processors like it does multiple tasks--so that old 68k multi-tasking software can just run as usual, and let the O/S handle the details--after all, that's what it's there for. Also, if you're going for the retro market, make sure ST/TT systems can handle it, as well as 68K Nac systems--include multi-processing patches to the various O/Ss if need be.

I saw that you opened an ad-hoc thread about this topic, but I'll answer here: you're asking for the impossible.

Specifically, 64 bit and/or SMP support CANNOT be added to some old o.ses, without killing the backward-compatibility with the old applications.

This is something which was extensively discussed here in some other thread, where you can find technical details about it.
Quote:

3: It's fine to produce a separate chip for the embedded--or any other-market if the market will support it; Mt produced the 68050, for instance, for just that reason

Motorola never produced any 68050. And unfortunately dropped the 68K family development to focus on PowerPCs, albeit it created some 68K "variants / reductions" for the embedded market (but not big changes / evolutions).
Quote:

4: Note that my mother was raised in England; a British "nice" is about equivalent to a Yank "Way Cool"...

I was born in USA (Connecticut), but at the time I spoken "Siculamerican" (a mix of Sicilian and American: Car -> Carru; Brooklyn -> Brucculina; Shower -> Sciaura, etc. etc. etc. ) and I still don't speak a good English/American, so sorry for my macaronic writings.
Quote:

5: There should be easy to read/use docs--while the RKM is far from the worst documentation I've seen--I read the original WordStar manual!--it falls flat on its face for someone trying to program BASIC,

RKMs are good enough: they give a good amount of information still today. Can be improved, but who can do it? Is it really interesting?
Quote:

and, frankly, BASIC--HiSoft BASIC II, usually--is my language of choice. I can put a dot on a screen with a single line of code--let's see you do that in C or Pascal!

As someone else stated, this can be done as well in Pascal (Turbo Pascal was my favourite language in the second half of '80s 'til all '90s with its beautiful successor: Delphi), and even in C. There are also TONs of libraries which can do much better, and that the HiSoft BASIC lacks.
Quote:

7: I think the issues with the o/s and user programming languages each deserve their own thread; I'll try to start them tonight.

See above: already discussed A LOT of times here. You're asking for the impossible.
Quote:

8: Thanks all for the serious responses, and have a Merry XMas, Chapp0y Chabucha, Happy New Year, and/or whatever else may apply!

https://www.youtube.com/watch?v=38x6kWB-xD4

@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @matthey I can argue that 1 bit processor can have as many as 32 instructions, compared to a 32bit CPU that can only have 1 instruction, and there for the 1 bit processor has better code density then 32 bit CPU. I find the argument about code density to be silly at best, just looking up the 68060 cpu. https://en.wikipedia.org/wiki/Motorola_68060 • 8 KB DCache (4-way associative) • 8 KB ICache (4-way associative) • 96 byte FIFO Instruction Buffer • 256 Entry Branch Cache • 64 Entry ATC* MMU Buffer (4-way associative) It has (8*1024)+(8+1024)+96+256+64 = 16800 bytes / 16.4 Kbytes of cache. PowerPC PA6T has L1 cache 64+64 KB/core L2 cache 2 MB/core One core in PA67T has 4 times the cache size of 68060, http://cache.freescale.com/files/32bit/doc/data_sheet/MPC7455EC.pdf the PowerPC 7455 (G4) has 32 Kbyte Cache, so it has 2 x the cache size of 68060. So yes the instructions might take more space, but cache size is also bigger, unless your only calculation with only number of +/-32,768, or 65,535, a real 32bit CPU is better. Not to consider the fact that PA6T has two cores with 64K cache, and can do twice the work load. Even with considering things like altivec, out of order execution and so on.

You're comparing apples to oranges: they have NOT the same transistors budget!

The 68060 shines compared to a "similarly-sized" PowerPC.

@WolfToTheMoon Quote:

WolfToTheMoon wrote: @NutsAboutAmiga Quote: I find the argument about code density to be silly at best It's not silly if you have a transistor and/or power budget - in the embedded world that's often the case. PA6T is a piece of shit CPU even with 40 times the cache of 68060, evident by the fact that almost no one used it for anything.

*

@matthey Quote:

matthey wrote: Quote: cdimauro wrote: @matthey: the main problem is that now there's RISC-V as the big contender. It'll leave less and less space in the embedded world, and erode A LOT of ARM market. RISC-V has competitive code density for RISC and is an open ISA which is appealing and competitive. They are doing many things right as far as development but the ISA has drawbacks too. It is simplistic, lacks personality and has too many variations. There are developers who don't like it. More choices are good. There used to be more embedded choices but the number of ISAs has shrunk as the market has exploded.

Don't get me wrong: I have a similar opinion on RISC-V.

I wanted only to point out that, whether we like or not, this new ISA will take a lot of market share, to the detriment of other ISAs.
Quote:

Quote: BTW, x86/x64 can switch back and forth between real -> protected 16/32 bit -> 64-bit long mode. You're not forced to stay on protected mode once you're there. If you have an o.s. running, then yes: you're locked there, but the same happens on other ISAs (ARM included). The good thing of ARM is that it has some "special execution modes" in 32-bit mode, like Thumb1/-2, ThumbEE, Jazille, where you can switch back and forth without leaving the 32-bit execution mode. An important part of the question I answered was about compatibility. It should be possible for an enhanced 68k CPU and AmigaOS to allow 64 bit and 32 bit applications to execute simultaneously using different modes. Perhaps this could provide better compatibility but also may cause too much complexity in the AmigaOS. Simultaneous 64 bit and 32 bit modes are not a problem for a CPU.

The problem is actually represented by the Amiga o.s. itself (and successors / rewritings, which share exactly the same issues), that cannot be extended/ported to 64-bit (or SMP) without losing the backwards-compatibility with the existing code.

If the aim is to have the "good (?) old" Amiga software running on a modernized 68K ISA, then there's no need for a 64-bit extension of it, neither for adding SMP: extending the existing 32-bit ISA is enough.

Fortunately, this isn't required for other markets, of course. And here (perfect) binary-compatibility is not a requirement as well (but source-level compatibility is a nice to have feature).
Quote:

Quote: NutsAboutAmiga wrote: One core in PA67T has 4 times the cache size of 68060, Larger caches per core use more transistors resulting in fewer cores or more die area used which adds to production costs. This also results in higher idle energy use and a longer latency to access the cache (probably at least 3 cycles to access L1 caches where the 68060 is 1 cycle). The primary reason multi-level caches were created was to avoid the latency increase of larger caches. Improving code density increases the amount of code in the ICache instead of enlarging the caches. This can slow the decoder and pipeline but can be cheaper than enlarging the caches. There are no free lunches in CPU design.

I agree. And the 68K family has other advantages other than a very good code density: they have a good average number of instructions needed/generated, and a low number of memory accesses (which is also related to the very good code density -> less memory reads for fetching the instructions).

It's really difficult to find (and create) an ISA which is good in all such critical parameters/features.

@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.

Note that the Amiga version of Free Pascal does contain its own memory manager, which means all memory allocated using standard Pascal memory functions (and not going to exec.library directly) will be freed on program exit, and cause no memory leaks to the system as a whole. Same applies to open files, all files opened via standard Pascal file handling functions will be properly closed on exit, even if the programmer forgot it. (These might also be true for some implementations of libc on Amiga, no clue.) In this case, basically the language's runtime library is doing the "resource tracking" for you, which is normally the task of the OS on more advanced systems.

Having this said, of course it's still best practice to close files/free memory anyway in your code, but the library of the language has this safety net for the programmer at least.

Modern Pascal has also reference counted objects and strings, which are managed automatically, so if your program leaves the scope of them and their reference count is zero, they get freed.

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)