OSDev.org

Rusky wrote:I think you have a problem of "anything I don't understand is puke."

Rusky wrote:The only thing in that list that's absolutely necessary is marking pointer ownership.

Rusky wrote:Marking pointers as owned and borrowed (managed is gone and has been replaced with standard library types Rc<T> and Gc<T>) is the core feature of Rust pointer safety. Much like your language marks variables with ranges, Rust marks which place in the code is responsible for managing memory. It doesn't do anything behind your back, it doesn't generate any extra operations at runtime, it just enables better static analysis.

Rusky wrote:You just have two symbols for pointer types in most code- ~u32 is an owned pointer and &u32 is a borrowed pointer. Owned pointers are freed when they go out of scope (so you can't leak memory) and track moving ownership (so you can't do multiple frees or use them from multiple threads, etc.), and borrowed pointers are verified not to outlive the owner (so you can't use after free or keep a reference when transferring ownership).

Rusky wrote:Marking safety extends this so you (or a library) can define new uses of pointers and enforce that they are used as intended. There is a third type- *u32 is a raw pointer and is used to implement new abstractions (like shared atomic types) and to interface with C. Safe is the default, so you only have to mark things unsafe in the implementation of new abstractions, like mutexes, reference counters, etc. This is a good thing, as the compiler makes sure you know the places you could screw up, and encourages you to put them behind interfaces rather than scattering them everywhere.

Rusky wrote:Traits and implementations are, in general, not related to pointers. They are used to specify interfaces and that specific types implement them. Some of these are built-in and automatically determined by the compiler. For example, there's a Copy trait (it could have been renamed, not sure) that means a type is copyable without extra care like dealing with ownership moves.

Rusky wrote:Vector types are just arrays, without C's pointer decay or other such nonsense. They are bounds-checked at runtime to maintain pointer safety, but I agree it would be more useful to do this with dependent types. They haven't done this because other language features are higher priority- the team is not opposed to it and it could be added in the future. Vectors do currently have some built-in behavior like resizing for heap-allocated vectors that is in the process of moving to the standard library.

Rusky wrote:Attributes have nothing to do with pointer safety. They're used for what is essentially the equivalent of command line arguments that are stored in the source file. Linking, warnings, etc. They're also used for conditional compilation, which I don't get your objection to since your language has it in a very similar form.

Rusky wrote:Macros have nothing to do with pointer safety in Rust. They are, however, better than C macros (which are why, I assume, you call them puke)- they are based on the AST rather than text, so there's no problems with e.g. extra parentheses around arguments, and they are clearly marked- all macro names end with !. So assert!(), fail!(), println!(), are basically functions on actual language constructs that run at compile time. They also let printf be type checked at compiler time.

Rusky wrote:Lambdas and closures have nothing to do with pointer safety. They are made safe by it, but nothing else. They don't hide anything behind your back either- their environment, the compiler-checked version of the "void *user" parameter for callbacks in C can be specified to live on the stack or heap just like in C.

Rusky wrote:Generic functions have nothing to do with pointer safety. Instead, they have to do with not forcing the programmer to write braindead copy-pasted versions of functions on things like lists, trees, etc. without losing the ability of the compiler to check things.

Brendan wrote:For example, I don't understand how the compiler knows that you haven't used a borrowed pointer when you should've used an owned pointer (or used owned when you should've used borrowed). If it can't determine that you've used the right pointer, then it just converts one problem into a different problem without reducing the total number of problems. If it does know which pointer you should've used, then it could've auto-detected the owned/borrowed part instead of placing the burden on the programmer. Regardless of how you look at it, it's useless.

I also don't understand how it works for shared global data. For an example; let's imagine you've got a "main" function that detects if the CPU supports AVX or not and sets a global function pointer; then starts 10 threads, and then the main/initialisation thread terminates. After that those 10 threads use the function pointed to by the function pointer. Who owns this function pointer and who has borrowed it? If the main/initialisation thread owned it what happens when the main/initialisation thread terminates (the lifetime of the owned pointer expires while 10 threads are still borrowing it)?

Brendan wrote:For another example, what happens if you've got one global shared pointer to an "8:8:8" pixel buffer (a pointer to u32 data that was allocated on the heap) and another global shared pointer to a "5:6:5" pixel buffer (a pointer to u16 data that was allocated on the heap); and you've got 3 threads. One thread converts "8-bit green" from one buffer into "5-bit green" and stores it in the other buffer while doing Floyd–Steinberg dithering for green; and the other 2 threads do the same for red and blue at the same time (note: this is the only way I've found to use multiple CPUs to speed up Floyd–Steinberg dithering). Now let's also say that there's other threads drawing data in the "8:8:8" pixel buffer, except there's actually 2 of these "8:8:8" pixel buffers and you do something like page flipping (e.g. swap the global pointers to the "8:8:8" pixel buffers before starting the conversion/dithering so that other threads can be drawing in one buffer while your 3 threads are processing the other). Which of all these pointers are owned and which are borrowed? How does Rust know that the "blue thread" is only using the pointer/s to access the bits corresponding to blue? How does Rust know that no thread accesses anything beyond the end of a buffer?

Brendan wrote:I'm not sure I want to get into memory management; but I've come to the conclusion that only having a single memory allocator is stupid (bad for cache coherency, bad for type checking, bad for profiling memory usage, etc). Also note that my OS has almost always had "process space" and "thread space" (with different allocators for different spaces) too. Once you start looking at having lots of special purpose allocators everywhere, marking all those places sounds like a nightmare.

To improve performance I often deliberately "leak" memory - e.g. rather than freeing all the little pieces one at a time before a thread or process terminates, I'll just terminate the thread or process and let the kernel free the underlying pages. Of course (for thread termination) this only works when the OS has "thread space" (a large part of the virtual address space that is thread specific).

Brendan wrote:So the average programmer would get tired of bothering with owned/borrowed, and would just use raw pointers for everything? Cool!

Brendan wrote:Once you get rid of owned/borrowed everything can be copied safely without traits.

Brendan wrote:I don't have a preprocessor at all (no macros and no conditional compiling). Instead of conditional compiling I rely on code optimisers and dead code elimination (e.g. rather than doing "#define USE_SOMETHING" and "#ifdef USE_SOMETHING" I'll do "const bool use_something = true" and "if(use_something) {"). Instead of macros I just have functions. Java does something similar.

I do have "multi-target", but this is only useful for a specific use case; and for that specific use case it's less hassle for the programmer and much more powerful than conditional code can be. For example; one of my ideas (for unit testing) is to compile all versions of a multi-target function that can be executed, and automatically check if they're all equivelent (e.g. so that it's easy to determine if your optimised assembly version/s of a function behave the same as the original higher level code version). Also note that my "multi-target" is designed to allow (e.g.) many different versions of a function for 32-bit 80x86, where different versions use different CPU features (e.g. with/without MMX, with/without SSE, etc) and the compiler automatically selects the best version that the target CPU supports (based on target CPU's supported features).

Brendan wrote:In my opinion, once you fix all the problems with "C like" macros (e.g. including the ability to do type checking on macro parameters), you end up with functions.

Brendan wrote:Just use function pointers.

Brendan wrote:I want to make it easier for programmers to write fast code than it is for them to write slow code. I need to encourage programmers to write the best code for their specific case and force them to actually think about what their code is asking the CPU to do; and I need to prevent them from just using "works for everything but ideal for nothing" trash.

For an example; let's say someone needs a list sorted in descending order. The best way is to create the list in descending order in the first place. The worst way is to create the list in random order because it's easier, then use a generic "sort()" to sort it in ascending order because it's easier, then use a generic "reverse()" to convert it into descending order because it's easier.

Brendan wrote:Without the "in edx", parameters get passed on the stack.

Rusky wrote:

Brendan wrote:For another example, what happens if you've got one global shared pointer to an "8:8:8" pixel buffer (a pointer to u32 data that was allocated on the heap) and another global shared pointer to a "5:6:5" pixel buffer (a pointer to u16 data that was allocated on the heap); and you've got 3 threads. One thread converts "8-bit green" from one buffer into "5-bit green" and stores it in the other buffer while doing Floyd–Steinberg dithering for green; and the other 2 threads do the same for red and blue at the same time (note: this is the only way I've found to use multiple CPUs to speed up Floyd–Steinberg dithering). Now let's also say that there's other threads drawing data in the "8:8:8" pixel buffer, except there's actually 2 of these "8:8:8" pixel buffers and you do something like page flipping (e.g. swap the global pointers to the "8:8:8" pixel buffers before starting the conversion/dithering so that other threads can be drawing in one buffer while your 3 threads are processing the other). Which of all these pointers are owned and which are borrowed? How does Rust know that the "blue thread" is only using the pointer/s to access the bits corresponding to blue? How does Rust know that no thread accesses anything beyond the end of a buffer?

Rust's pointer safety isn't granular enough to deal with members of an array separately, let alone bit fields. I wouldn't put those pointers in globals (what if you want to run more than one conversion at once?), but the problem still stands. If they were in globals you wouldn't have the owner problem; when they're not in globals they're owned by whatever function is controlling those threads (as that's the code responsible for allocating the buffers and handing them out).

As for knowing that each thread only accesses certain bits, that's going to be up to you, especially considering that the 5:6:5 are not accessible atomically anyway. I will emphasize that this case is no worse than your language or C, but other cases are better.

Rusky wrote:

Brendan wrote:I'm not sure I want to get into memory management; but I've come to the conclusion that only having a single memory allocator is stupid (bad for cache coherency, bad for type checking, bad for profiling memory usage, etc). Also note that my OS has almost always had "process space" and "thread space" (with different allocators for different spaces) too. Once you start looking at having lots of special purpose allocators everywhere, marking all those places sounds like a nightmare.

To improve performance I often deliberately "leak" memory - e.g. rather than freeing all the little pieces one at a time before a thread or process terminates, I'll just terminate the thread or process and let the kernel free the underlying pages. Of course (for thread termination) this only works when the OS has "thread space" (a large part of the virtual address space that is thread specific).

Rust already has arena allocators in its standard library. They simply give you borrowed pointers with the same lifetime as the allocator, which is all handled by the library declarations so you generally don't have to deal with it. This also solves your "leak" use case. In the more complicated case where memory gets allocated and freed, I don't see how marking pointers from different allocators is any worse than your system- you still have to keep track of which allocator to give memory back to. May as well have the type system help you.

Hmm, maybe with your own type wrapped around a raw pointer, implementing some traits... but that would need a way to specify at compile time which allocator it belongs to, as well as which type it points to... I guess that's a horrible idea, because every allocator needs to have its free() called a different way for efficiency, and every pointer type needs a different layout in memory. Oh wait. Pointers and arrays are already generics built into every language on the planet.

typedef struct file_buffer {
    struct *nextFreeList;
    char *fileName;
    int fileHandle;
    uint8_t *buffer;
    unsigned int bufferSize;
    unsigned int bufferPos;
} FILE_BUFFER;

FILE_BUFFER fileBufferPool[MAX_BUFFERS];    //Note: Assumes kernel supports "allocation on demand"
int nextUntouchedSlot = 0;
FILE_BUFFER *freeFileBufferList = NULL;

FILE_BUFFER *createFileBuffer(char *fileName) {
    int slot;
    FILE_BUFFER *fileBuffer;
    int fileNameLength;
    char *tempFileName;

    // Pre-allocate copy of file name string

    fileNameLength = strlen(fileName);
    tempFileName = malloc(fileNameLength + 1);
    if(tempFileName == NULL) {
        return NULL;
    }
    memcpy(tempFileName, fileName, fileNameLength);

    // Allocate the file buffer structure

    if(freeFileBufferList != NULL) {
        fileBuffer = freeFileBufferList;
        freeFileBufferList = fileBuffer->next;
    } else {
        slot = nextUntouchedSlot++;
        if(slot >= MAX_BUFFERS) {
            nextUntouchedSlot--;
            free(tempFileName);
            return NULL;
        }
        fileBuffer = &fileBufferPool[slot];
    }

    // Pre-configure it and return it

    fileBuffer->fileName = tempFileName;
    fileBuffer->fileHandle = -1;
    fileBuffer->buffer = NULL;
    fileBuffer->bufferSize = 0;
    return fileBuffer;
}

int destroyFileBuffer(FILE_BUFFER *fileBuffer) {

    // Do sanity checks

    if( (fileBuffer < &fileBufferPool[0]) || (fileBuffer > &fileBufferPool[nextUntouchedSlot]) ) {
        return FAIL;
    }
    if( (fileBuffer - &fileBufferPool[0]) % sizeof(FILE_BUFFER) != 0) {
        return FAIL;
    }

    // Do cleanup

    if(fileBuffer->fileHandle >= 0) close(fileBuffer->fileHandle);
    free(fileBuffer->fileName);
    if(fileBuffer->buffer != NULL) free(fileBuffer->buffer);

    // Add structure back to pool and return OK

    fileBuffer->nextFreeList = freeFileBufferList;
    freeFileBufferList = fileBuffer;
    return OK;
}

• the "freeFileBufferList" could be a lock-free list (using "compare and swap")
• the "slot = nextUntouchedSlot++;" and "nextUntouchedSlot--;" can both be done atomically on 80x86 ("lock xadd" and "lock sub")
• with the previous 2 things, the entire allocator and deallocator could be lockless
• you could add a "bool isFree;" member to the structure if you want better sanity checking
• it has good cache locality (e.g. all FILE_BUFFER structures are as close together as possible)
• the "recycle recently freed" behaviour helps avoid cache misses
• if someone makes a mistake and tries to allocate an infinite number of these structures, it's going to run out reasonably quickly and won't allocate all RAM and cause the OS to start swapping (it's like having fine granularity RAM quotas)
• it'd be trivial to add a global "bool aboutToTerminate;" and do "if(aboutToTerminate) { return OK }" in the middle of the cleanup in "destroyFileBuffer()"
• the "lazy cleanup" makes it much easier to maintain the rest of the code (note: similar benefits as constructors and destructors in OOP languages)
• after profiling it, you might (or not) find that it's better to remove the "if(fileBuffer->buffer != NULL) free(fileBuffer->buffer);" instead of freeing and re-allocating those

Rusky wrote:

Brendan wrote:Once you get rid of owned/borrowed everything can be copied safely without traits.

...according to the language. Until you accidentally copy a pointer and free it twice. Which is a problem you have regardless of whether your language has owned/borrowed, so the language should help you with it to improve its ability to catch errors.

Rusky wrote:

Brendan wrote:I don't have a preprocessor at all (no macros and no conditional compiling). Instead of conditional compiling I rely on code optimisers and dead code elimination (e.g. rather than doing "#define USE_SOMETHING" and "#ifdef USE_SOMETHING" I'll do "const bool use_something = true" and "if(use_something) {"). Instead of macros I just have functions. Java does something similar.

I do have "multi-target", but this is only useful for a specific use case; and for that specific use case it's less hassle for the programmer and much more powerful than conditional code can be. For example; one of my ideas (for unit testing) is to compile all versions of a multi-target function that can be executed, and automatically check if they're all equivelent (e.g. so that it's easy to determine if your optimised assembly version/s of a function behave the same as the original higher level code version). Also note that my "multi-target" is designed to allow (e.g.) many different versions of a function for 32-bit 80x86, where different versions use different CPU features (e.g. with/without MMX, with/without SSE, etc) and the compiler automatically selects the best version that the target CPU supports (based on target CPU's supported features).

Sometimes it's simply impossible to get away without conditional compilation. You can use optimized-out if-branches all you want until one of them uses some API or machine instruction that doesn't exist on your target platform.

Rusky wrote:

Brendan wrote:In my opinion, once you fix all the problems with "C like" macros (e.g. including the ability to do type checking on macro parameters), you end up with functions.

Do these functions run at compile time so you can type-check printf? Can they manipulate syntax so you can have assert fails, log output, etc. print the source file and line, or generate new items like entries in a statically-generated table?

Rusky wrote:

Brendan wrote:I want to make it easier for programmers to write fast code than it is for them to write slow code. I need to encourage programmers to write the best code for their specific case and force them to actually think about what their code is asking the CPU to do; and I need to prevent them from just using "works for everything but ideal for nothing" trash.

For an example; let's say someone needs a list sorted in descending order. The best way is to create the list in descending order in the first place. The worst way is to create the list in random order because it's easier, then use a generic "sort()" to sort it in ascending order because it's easier, then use a generic "reverse()" to convert it into descending order because it's easier.

Even the Linux kernel uses generics for things like walking linked lists. Whether you acknowledge it or not, there are some functions and types that are always exactly the same, and there's no point in duplicating them just for the sake of the few cases where they should be different.

embryo wrote:

Brendan wrote:Without the "in edx", parameters get passed on the stack.

For me it seems like heavy mix of the high and low levels. We can have a low level function, implemented in assembly, but it's parameters are exposed to the high level. If we use something like "in edx" then it leads to some restrictions for the compiler and to some additional attention from the developer. But if the function parameters always have the same meaning as for the standard high level function call, then the compiler is free to choose any method of parameter value access and the developer makes less bugs because the call has no difference from it's standard meaning.

Brendan wrote:I'm not too sure that I've understood what you're saying here...

Brendan wrote:Are you suggesting something like "myParameter as u32 in any", where the compiler chooses which register to use for "any"?

Brendan wrote:The conversion would be done by a video driver for "generic framebuffer" (everything else involving graphics would/should be resolution independent); so you only need multiple conversions at the same time when you've got multiple separate video drivers.

If the destination buffer is cleared to zero first; then it's simple to do an atomic "lock or [dest],eax".

Brendan wrote:Don't be silly. Different allocators need different code, so generics are a waste of time. Of course it's (almost) never just memory allocation and deallocation.
...
Basically; even though this is already an allocator designed for one specific purpose, there's still different things that can be done to make it better (more specific) for the actual use case.

Brendan wrote:(specifically; the "you could add a "bool isFree;" member to the structure if you want better sanity checking" part). If it's not a problem for a language that doesn't have owned/borrowed (like C), then...

Brendan wrote:These problems aren't really possible. There's 2 compilers (one used by programmers to create a "portable executable" and one used by the end-user to convert it into a native executable for their CPU). If it uses an instruction that doesn't exist then the worst case is the user gets a compile time error. Of course these end-user compile time errors should be rare ("multi-target" requires a higher level code version in case none of the assembly versions are usable on the end-user's CPU). For my OS there is only one API (the kernel API) and it uses a standardised set of error codes and guarantees that an unsupported function returns the standard "unsupported function" error. I'm not expecting this language to be ported to other people's OSs (it's specifically designed for my "everything redesigned" OS and I'd assume it'd be like driving a submarine on a highway for other OSs).

Brendan wrote:I have no intention of supporting functions with variable argument lists. There's no need to manipulate syntax so you can have assert function that accepts a bool (and an error message, line number, whatever) as an argument. I have no idea what you mean by "log output".

Brendan wrote:For statically generated tables, just use a function instead. For example; let the compiler convert "myFunction(arg1 as range 0 to 123, arg2 as range 0 to 456") (myResult as u32)" into the equivalent of "myTable[123][456] as u32" at compile time. Note: some restrictions apply, mostly the function would need to be a "pure function" and the resulting table would need to be reasonably sized.

Rusky wrote:

Brendan wrote:Don't be silly. Different allocators need different code, so generics are a waste of time. Of course it's (almost) never just memory allocation and deallocation.
...
Basically; even though this is already an allocator designed for one specific purpose, there's still different things that can be done to make it better (more specific) for the actual use case.

Your example is not hindered by owned/borrowed pointers, nor is there a reason to limit that system to file_buffers. You could parametrize it with a struct that implements a trait to handle the file_buffer-specific construction and destruction, as well as potentially a trait to provide hooks for error handling, etc.

Rusky wrote:None of your bullet points has anything to do with file_buffers specifically- they would be equally if not more useful for things as widely varied as game engines, network drivers, small thread/coroutine contexts, etc. So you can copy and paste your allocator around for different use cases and then add all your optimizations to all of them separately, or you can do it in one place.

Rusky wrote:

Brendan wrote:(specifically; the "you could add a "bool isFree;" member to the structure if you want better sanity checking" part). If it's not a problem for a language that doesn't have owned/borrowed (like C), then...

Oh, so your language catches that at compile time without adding a field to every allocated object?

Rusky wrote:

Brendan wrote:These problems aren't really possible. There's 2 compilers (one used by programmers to create a "portable executable" and one used by the end-user to convert it into a native executable for their CPU). If it uses an instruction that doesn't exist then the worst case is the user gets a compile time error. Of course these end-user compile time errors should be rare ("multi-target" requires a higher level code version in case none of the assembly versions are usable on the end-user's CPU). For my OS there is only one API (the kernel API) and it uses a standardised set of error codes and guarantees that an unsupported function returns the standard "unsupported function" error. I'm not expecting this language to be ported to other people's OSs (it's specifically designed for my "everything redesigned" OS and I'd assume it'd be like driving a submarine on a highway for other OSs).

So you solve those problems with conditional compilation (multitarget). Good, we agree.

Rusky wrote:

Brendan wrote:I have no intention of supporting functions with variable argument lists. There's no need to manipulate syntax so you can have assert function that accepts a bool (and an error message, line number, whatever) as an argument. I have no idea what you mean by "log output".

So you want the programmer manually to type in the source file name and line when they assert, when they write out a log message, etc.?

Rusky wrote:

Brendan wrote:For statically generated tables, just use a function instead. For example; let the compiler convert "myFunction(arg1 as range 0 to 123, arg2 as range 0 to 456") (myResult as u32)" into the equivalent of "myTable[123][456] as u32" at compile time. Note: some restrictions apply, mostly the function would need to be a "pure function" and the resulting table would need to be reasonably sized.

Doesn't work when you don't just want a table as an optimization, like with processor-defined tables.

Rusky wrote:edit: you do seem to be fond of copy and paste; at least look at something that tries to make it not suck First Class Copy & Paste

Brendan wrote:I could parameterise it with a struct that implements a trait, but if I really wanted to obfuscate it (make it harder to read, harder to maintain, etc) then there are more effective ways (especially for C). I do agree that your "system of puke" wouldn't be limited to just file_buffers and could be recycled if I wanted to make other allocators worse too.

The "benefits" of making the code pointlessly over-complicated do not justify the disadvantages for the programmer/s themselves (trying to follow logic that's spread everywhere), for the people writing tools for the language, or for people trying to learn the language.

Brendan wrote:No, and neither does yours (oops, I mean someone else's) - Rust would let you free the same memory 20 times from within an "unsafe" block.

Brendan wrote:I've already provided several reasons why "multi-target" is not the same as conditional complication. It's bad that you can't read.

Brendan wrote:

Rusky wrote:Doesn't work when you don't just want a table as an optimization, like with processor-defined tables.

Yes it does. Note: What I mean here is that I'm too lazy to figure out all the very different things that you could've meant by "processor-defined tables" and show that it is possible for each possible case in the hope of getting lucky and covering whatever it was that you failed to describe adequately.

Brendan wrote:A smart person can invent something complicated; but it takes a genius to describe something complicated in a way that can be understood. Only a complete moron would write sentences like "Speculative execution of queued hypotheticals provides concurrency as a semantically transparent implementation optimization." and expect others to read it. Perhaps you should've attempted to clearly describe whatever your point might be, rather than merely providing a link to a seemingly random piece of academic gibberish?

Rusky wrote:

Brendan wrote:I could parameterise it with a struct that implements a trait, but if I really wanted to obfuscate it (make it harder to read, harder to maintain, etc) then there are more effective ways (especially for C). I do agree that your "system of puke" wouldn't be limited to just file_buffers and could be recycled if I wanted to make other allocators worse too.

The "benefits" of making the code pointlessly over-complicated do not justify the disadvantages for the programmer/s themselves (trying to follow logic that's spread everywhere), for the people writing tools for the language, or for people trying to learn the language.

It's called separation of concerns. Separating parts of the code that address separate issues (allocating memory, initializing a file buffer, etc.) makes code easier to read, maintain, and test. The only possible reason "logic that's spread everywhere" (not really) could be a problem is if you have a bad editor. Especially in your case where you want good IDE support, you could easily show the allocator and the file_buffer code right next to each other.

Rusky wrote:

Brendan wrote:No, and neither does yours (oops, I mean someone else's) - Rust would let you free the same memory 20 times from within an "unsafe" block.

As has been stated many times, outside of unsafe blocks you still get your code verified. There's a large difference of degree between "most code is verified" and "no code is verified."

Rusky wrote:

Brendan wrote:I've already provided several reasons why "multi-target" is not the same as conditional complication. It's bad that you can't read.

I can read, your reasons are just wrong. Multitarget provides multiple implementations of a function, which are selected based on the configuration of the target. That is the definition of conditional compilation.

Rusky wrote:

Brendan wrote:

Rusky wrote:Doesn't work when you don't just want a table as an optimization, like with processor-defined tables.

Yes it does. Note: What I mean here is that I'm too lazy to figure out all the very different things that you could've meant by "processor-defined tables" and show that it is possible for each possible case in the hope of getting lucky and covering whatever it was that you failed to describe adequately.

Statically declare the initial contents of your GDT using a function. I dare you to make that simpler and more clear than just using a table directly, and without requiring static constructors to verify that it's initialized (that *is* puke).

GDT[] as const u64 = {
    0                         ;NULL entry
    createGDTentry(0, u32.max, CPL0CODE)
    createGDTentry(0, u32.max, CPL0DATA)
    ...
}

functiondef createGDTentry(base as u32, limit as u32, type as u8) (result as u64) {
   ...
}

Rusky wrote:

Brendan wrote:A smart person can invent something complicated; but it takes a genius to describe something complicated in a way that can be understood. Only a complete moron would write sentences like "Speculative execution of queued hypotheticals provides concurrency as a semantically transparent implementation optimization." and expect others to read it. Perhaps you should've attempted to clearly describe whatever your point might be, rather than merely providing a link to a seemingly random piece of academic gibberish?

...or someone whose target audience knows those concepts already and wants to focus on what they actually did? Which, by the way, is right in the abstract: "Inclusions reify copy & paste edits into persistent relationships that propagate changes from their source into their destination." That way you could implement your file_buffer allocator, copy and paste it somewhere else for a different allocator, and then fixing a bug or adding a feature in one would (optionally) fix it in the other.

Brendan wrote:Code to allocate a file buffer and code to initialise a file buffer are very strongly related - when you create a file buffer you always do both (allocate then initialise).

Brendan wrote:Except you're using a deliberately biased comparison, and it's actually "most code is verified" vs. "most code is verified".

Brendan wrote:I see - you've artificially extended your private definition of "conditional compilation" to include cases where the programmer doesn't need define their conditions (e.g. "#define FOO") or specify most conditions (e.g. "#ifdef FOO").

Brendan wrote:Do you actually think this is hard?

Brendan wrote:Instead of saying "reify copy & paste edits into persistent relationships that propagate changes from their source into their destination" why didn't they just say "when you're trying to customise a copy to be suitable for something completely different/unrelated, optionally trash the original"?

Rusky wrote:

Brendan wrote:Code to allocate a file buffer and code to initialise a file buffer are very strongly related - when you create a file buffer you always do both (allocate then initialise).

But you don't always use the same combination of allocator and initializer, nor is every type's allocator different. Thus, there are cases that generics enable separation of concerns to a degree that it is still good.

Rusky wrote:

Brendan wrote:I see - you've artificially extended your private definition of "conditional compilation" to include cases where the programmer doesn't need define their conditions (e.g. "#define FOO") or specify most conditions (e.g. "#ifdef FOO").

Rust's conditional compilation specifies precisely the same information as multitarget (e.g. #[cfg(target_arch="x86")] as an attribute on the following item).

Rusky wrote:

Brendan wrote:Do you actually think this is hard?

Good work. Now, do a table that you want to fill out with a for loop. How well does that work without macros?

Brendan wrote:And yet the minor advantages for a few trivial cases still don't justify all the disadvantages.

Brendan wrote:Now; imagine I write 20 different versions of a function for "32-bit 80x86 assembly" (where each version uses different combinations of "possibly not supported" instructions) and only tell the compiler that all of them are for 32-bit 80x86; and then the compiler decides which one of those 20 different versions are best for the target CPU. Is this how "#[cfg(target_arch="x86")]" works (e.g. compiler auto-selects from many "32-bit 80x86" variations without any hint from the programmer)? Is this how conditional compiling works in C?

Rusky wrote:Can you give me a realistic scenario (e.g. an example of "looping macro table creation" from an existing project)?

Rusky wrote:

Brendan wrote:And yet the minor advantages for a few trivial cases still don't justify all the disadvantages.

Maybe in the use cases you've thought about. Not true in the general case.

Rusky wrote:

Brendan wrote:Now; imagine I write 20 different versions of a function for "32-bit 80x86 assembly" (where each version uses different combinations of "possibly not supported" instructions) and only tell the compiler that all of them are for 32-bit 80x86; and then the compiler decides which one of those 20 different versions are best for the target CPU. Is this how "#[cfg(target_arch="x86")]" works (e.g. compiler auto-selects from many "32-bit 80x86" variations without any hint from the programmer)? Is this how conditional compiling works in C?

I'm only going on what examples of multitarget you've given thus far. In any case, even with your extensions described here, it's still conditional compilation. The conditions are just more complicated- #[cfg] could just as well specify those variations (not sure if it does atm), but when you get to the point of writing a function in assembly 20 times you've reached my version of puke. Why are you writing assembly for many combinations of x86 features? Why are you, and not the compiler, translating your intent into the available machine instructions?

Rusky wrote:

Rusky wrote:Can you give me a realistic scenario (e.g. an example of "looping macro table creation" from an existing project)?

I would do it with the IDT if the linker had better relocation support; I currently do it for ISR stubs with nasm macros (hah, do that with a function); depending on your design you could do it for a static page table or two based on the layout of the kernel image.