00:00 <tabemann_> whereas my memory pool has a minimum block size of 4 bytes

00:00 <tabemann_> with no extra overhead

00:00 <tabemann_> the only issue with the memory pool is that each block has a fixed maximum size, and if less data is needed than the full block size it is wasted

00:01 <tabemann_> *the remainder is wasted

00:01 <veltas> Yeah I think you're trying to square a circle a bit on this one

00:03 <tabemann_> note that the heap can be combined with the memory pool, as the user can take space allocated on a heap and add it to the memory pool

00:04 <tabemann_> and that was my objective here

00:04 <veltas> You can avoid storing the size per-block if the size can be passed to free and the actual size is a deterministic function of requested size

00:04 <veltas> And if you are freeing something you generally either know or can remember how large it is

00:05 <veltas> It's been talked about that this is a 'broken' feature of C, C++ etc that free/delete does not pass size info (in C++ it really is, because classes absolutely know how large things are)

00:06 <veltas> This saves like 16 or 8 bytes per allocation on modern computers.

00:10 <tabemann_> I'm surprised that you actually implemented a compacting heap for a ZX Spectrum, btw

00:11 <veltas> I didn't!

00:11 <veltas> I said I started doing it and gave up because it turned out not to be worth it :P

00:11 <veltas> It might be worth it on an embedded device with very constrained RAM where the flash space is not an issue

00:12 <veltas> If you find yourself writing extra code to try and save space in the same space you're trying to save, you're doing it wrong

00:12 <veltas> Yes Mac and Windows both

00:12 <tabemann_> compacting heaps make it hard to write bug-free code though

00:13 <veltas> On Windows it 'hid' the details from you often because it would compact on a 64K boundary, and your segment registers would get mysteriously updated if it happened while your program was yielded

00:13 <tabemann_> because you need to keep on locking and unlocking blocks

00:14 <veltas> Yes, this is what I realised and that adds extra code, therefore the space lost by fragmentation is not as bad as the space (from extra code) *and* effort required by the compacting

00:14 <veltas> It would be worth it on e.g. x86 where you can hide the details like MS did

00:15 <veltas> Why would you be surprised?

00:16 <tabemann_> ?

00:16 <tabemann_> oh yeah

00:16 <tabemann_> I thought that the ZX Spectrum would be too small of a system to really support something like a real heap, with its overhead

00:18 <veltas> Definitely was constrained, heap is convenient though and I was writing a text editor so seemed worth it

00:19 <veltas> Had an array of pointers to text lines, means the line length can be more flexible and probably more memory efficient than what forth does

00:20 <veltas> Old Forth block editors just allocate the whole block to a number of fixed-length lines, short lines waste loads of space etc.

00:20 <tabemann_> yeah

00:21 <veltas> The thing wasting space on that project was trying to write code in C with SDCC

00:24 <veltas> The idea was to try and make an interactive environment with some kind of language, and I decided then that it would actually make more sense to create a small language and implement the *editor* and as much as possible in that language

00:24 <veltas> Even write the compiler and interpreter in the language, all you need then is to write the VM in machine code

00:25 <veltas> This is before I knew forth obviously, or the solution would have been painfully obvious

00:25 <tabemann_> yeah

00:26 <tabemann_> okay, I'm gonna have dinner now, will bbl

00:26 <veltas> I like rediscovering all the same problems others have solved

00:26 <tabemann_> definitely

00:26 <veltas> Have fun

00:33 <veltas> I think the right way to do a text editor with constrained space is to delimit lines where they are allocated, and leave space between them. Then you can compact if needed, or shuffle them along (less frequently than if they're all bunched up)

00:33 <veltas> The actual BASIC environment that comes with the Spectrum decided to delimit them in memory all contiguously, and then as lines are inserted all further lines must be moved along in memory, which is visibly slow in the editor!

00:35 <veltas> The Spectrum fit a decent amount of code in, because it was stored tokenised, values above $80 were used for keywords/built-ins/etc

00:42 <veltas> Just put everything in B-trees with traversal optimisations and then use a fixed-size pre-allocated pool for allocations, fully real-time. Just don't ask me to code the B-tree :P

00:58 <TangentDelta> It's annoying that the 6502 took off and became super popular. It's my favorite 8-bit microprocessor though :P

00:59 <TangentDelta> The 6800 is way more capable, but nowhere near as cheap as the 6502 was.

01:02 <veltas> 6502 is fine if you treat it like a 128-register RISC and don't think too hard about it

01:03 <veltas> What a true 8-bit processor it was

02:57 <tabemann_> back

02:57 <tabemann_> hey guys

02:58 <tabemann_> to me the big problem with the 6502 is that the index registers were 8-bit

03:05 <TangentDelta> Yeah. That's the most annoying thing for me.

03:06 <TangentDelta> It's not too bad with all of the different indirect indexed modes, but it's slower and takes up more code.

06:12 <siraben> today's advent of code was nice

18:05 <veltas> I am very slowly going through aoc when I have time and feel like it

18:05 <veltas> I did spend quite a while trying to optimise my big boy solution for day 1...