I tried doing it in Assembly two years ago, ended up spending hours and hours writing an Assembly standard library, then gave up and switched to Rust...
This year the Amiga has an 060 upgrade with an MMU, so perhaps I can figure out how to use that and have another go.
Not unworkable, but not the most relaxed environment for fast’n’fun cowboy coding. You typically have to reboot a lot.
A1000 has... something. The WORM (write once read many), RAM used for the kickstart, which is latched as read-only after the kickstart has been loaded from floppy by the bootstrap ROM.
What was the issue with lack of memory protection? If you're used to programming in C is there actually that much difference to running on a modern PC or embedded system?
I say it in jest but that's actually how I used to program a few years ago when I was working on large industrial pieces of software with long compilation time. You just have to be careful and check what you wrote before sending it to the machine.
I think "iterative" programming has made people really complacent when it comes to silly errors. Slowing down can often do wonder.
https://git.sr.ht/~q3cpma/aoc2024/tree/master/item/01
If you could post a repo link so I can look at some of the progress, I'd be grateful.
https://www.musixmatch.com/lyrics/Kraftwerk/Boing-Boom-Tscha...
Remember that brute force is also a solution in the AoC; had plenty of fun using SBCL to crack some problems where Pythonistas had to be clever, last year =)
- you can implement a hash table in C in about 125 LOC and reuse it.
- hash tables are not the only way to solve problems. hammer/nail
Only if you write/read your table in two separate passes. A tally needs mixed read/write to increment a counter, not just insertion, so it must be kept sorted during the table creation. Some kind of tree or linked list is probably better in this case.
> you can implement a hash table in C in about 125 LOC and reuse it.
I know. Anyone who uses C and never made at least a basic FNV1A/bucket-based hash table must be insane. But I wanted a small self-contained .c here and have become allergic to (void *); if I were to use C seriously, I'd fix it using a better preprocessor (à la https://github.com/etwyniel/c-generics).
> hash tables are not the only way to solve problems. hammer/nail
Eh, a tally seemed the most intuitive way for the 2nd part.
Insert each element in its sorted position. It will only degenerate if there are many more inserts than lookups, in which case a hash table would do nothing for you.
This could also be a good case for a radix structure.
> void* hash table
I would stay far from poor implementations of high level languages. Why use C if you want generics?
A reusable hash table can be implemented by implementing open addressing with 64 bit integer keys. Then if you have a fancy type you write a hash function and perform linked list chaining on the values.
Another way is to treat the keys as byte arrays.
> seemed the most intuitive way for the 2nd part.
Intuition is a kind of familiarity. There is no reason to learn C if you just write the techniques you already know in a less safe and more verbose way. You instead should be learning a new way to think about problems.
Last year I solved all the problems in C without external libraries [1] and I enjoyed it a lot. It forced me implement some low-level stuff that I had forgotten how to do (e.g. a heap) and to write some numerical routines myself (easier than you'd think!).
[1] https://github.com/sebastianotronto/aoc/tree/master/2023
Well, awk suffices to write a first-person shooter: https://news.ycombinator.com/item?id=34442528
I remember one of my naive brute force solutions from last year ended up allocating gigabtyes of memory. There were obviously more efficient solutions, but some of the inputs are pretty large and so hefty allocations might be difficult to avoid.
I do allow myself a 5Gb disk to which I can page out memory.
I think I'll follow in your footsteps. STM32F7 with 320k but with bare metal Rust :)