[M3devel] backend interface vs. types vs. forward references?

[Jay K]

The passes I'm talking about I think will be fast.
True the backend is very slow but I don't think this will matter.
The earlier will passes will ignore most of the data.
The cost will only be in the extra but ignored serialization.
And even then, it might be better -- if the ordering is a certain way
and guaranteed, once it hits certain opcodes, it will know the types
are all done and start over, without walking each opcode one at a time.

I tried building m3cc on virtual machines with only 256MB and it failed.
I had to up to 384 MB. If I cal recall correctly.

Granted, we don't always build m3cc.

Remember that optimized builds would often use "unit at once"
 compilation, so the entire gcc tree would be in memory.
Now, currently, we never do that for Modula-3, because of a bug
where it throws out functions that are needed to be kept.
But for C/C++ it is not unusual (again, including compiling m3cc).
The tree representation is presumably not much different/smaller than
the m3cg representation. For actual C/C++ there might be a bigger difference,
what with comments/whitespace removed.
But from the gcc point of view, Modula-3 source is already in an encoded binary form.
Granted, the strings are duplicatd.

Still, the access pattern remains linear.
So it doesn't increase working set. Just virtual address space requiremens.

This is something I learned reeently working with large data -- linear access
patterns are what is good and keeps working set down, vs. random access.

Plus, the file gets closed which does free a little of resources, though
probably less than are being additional consumed.

 - Jay

----------------------------------------
> Date: Mon, 4 Oct 2010 16:45:46 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] backend interface vs. types vs. forward references?
>
> Quoting Jay K :
>
> > I think I'll just solve this in the backend by making a few passes.
> > Maybe something with specific passes where early passes only pay
> > attention to certain opcodes, that declare types.
>
> I'm not really happy with multiple passes within the backend just to
> make gcc happy. The performance of the gcc backend is already poor
> compared to an integrated backend and to what M3 should be able to
> achieve. How much will it cost wrt. performance?
>
> > The new/current "replay" stuff will maybe go away.
>
> Hm, I must have missed that.
>
> > The new/current keeping of the entire file in memory will stay
> > unless someone has strong evidence/argument that is shouldn't.
>
> Keeping the whole (intermediate code) file in memory should be fine,
> unless we get problems for large generated files on small machines
> somewhere.
>
> How big are the intermediate files for all our own sources?
> Can you write out some statistics?
>
> Olaf
> --
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
>