[Oberon] maxCode limit in ORG

[Charles Perkins]

Thanks Michael and Jörg,

I agree that large modules are to be avoided and factoring a module is
better than just relaxing limits, especially without understanding the
consequences. Having bumped up against the limit (and then refactored my
code) I wanted to know the nature of that limit.

Much appreciated,
Chuck

On Wed, Apr 7, 2021 at 2:09 PM Michael Schierl <schierlm at gmx.de> wrote:

>
> Hello,
>
>
> Am 06.04.2021 um 20:40 schrieb Joerg:
> > Chuck
> >
> > It‘s indeed arbitrary. Keep in mind: it is in words. So, 8000 means ~32
> kByte.
> > It’s generally a bad practice to generate modules bigger than 32 kByte.
> Altough there might be special cases where a split in several modules is
> not wanted or generates „strange“ module borders.
> >
> > Indeed on my FPGA system with 15MB of memory and 1MB for color display,
> I could increase this limit, but I did not.
>
> In my experience, when increasing the limits of the compiler you first
> hit the 64KB globals limit, before running into any real RAM shortage.
>
> The arrays in the compiler have static sizes, so if you increase the
> limits, the arrays will grow even if not needed.
>
>
> Regards,
>
>
> Michael
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20210407/213394b3/attachment.html>