IRC channel logs

<OriansJ>ericonr: the only similiar idea I could think of would be to read the whole file in as a single read call (after using fseek and ftell to determine the size of the file) and then use that as an in memory array.

<OriansJ>then create a massive array to shove the output; buffer it there and then just dump it all in a single write call

<OriansJ>The write will definitely be more complex but I could minimize that by making https://github.com/oriansj/M2-Planet/blob/master/test/common_x86/functions/file.c have a 8MB buffer and not call write until it is full or an fflush is called (which would require fflush to be added to all of the programs to ensure no output is lost)

<deesix>OriansJ, why is https://paste.debian.net/1167513/ declaring malloc twice? Am I reading it right? Also, what's up with shifting for aarch64?

<deesix>s/declaring/defining/

<nimaje>probably that first malloc should be changed to brk

<deesix>OK, that seems to be fixed in the commit. Also the SCM usage is changes (which is another thing I was unsure about).

<deesix>*changed

<xentrac>hmm, can SDCC compile itself?

<ericonr>in that it can parse the C it's using>

<ericonr>?

<ericonr>because otherwise it's a very uC oriented compiler written to run on a hosted system, so I don't think it's at all portable to one of its targets

<ericonr>OriansJ`: hmm, I don't think I understand enough about the problem domain, sorry. It was mostly a random suggestion.

<xentrac>ericonr: I was wondering if it had any targets with enough memory space to hold all its code

<xentrac>or some kind of reasonable overlay scheme

IRC channel logs

2020-10-22.log