OSDev.org

Brendan wrote:In this case EDI contains the address of the structure, "offset" is a keyword (not a variable) which means "get the offset of a member within a structure", and "union.asmdata" says which member of which structure to get the offset of.

void fieldAccessFunction(GPR32 objectAddressReg, GPR32 fieldOffsetReg, GPR32 resultReg)
{
  mov resultReg, [objectAddressReg + fieldOfffsetReg]
}

Brendan wrote:but that's strange in assembly (where square brackets are used for the equivalent of pointer dereferencing) and would mean the assembler has to know the types of all registers (which would be complicated and likely to fail in non-trivial cases) just to figure out what type of structure it is.

Brendan wrote:I do have a concept called "data properties" though. For example, if you've got a variable "foo" then "foo.max" gets the maximum value the variable can hold, "foo.size" gets the amount of bytes the variable consumes, etc.

Brendan wrote:What I'm considering doing is adding an "offset" property, so that people can do "myStructure.myMember.offset" to get the offset of myMember in the structure. In that case the original instruction would become "mov eax,[edi+union.asmdata.offset]" or (using the structure type's name directly instead of the function's input parameter name) "mov eax,[edi+myTaggedUnion.asmdata.offset]"

mov(eax, myTaggedUnion.asmdata);
// mov definition
void mov(GPR32 resultReg, int sourceValueAddress)
{
...
}

embryo wrote:

Brendan wrote:In this case EDI contains the address of the structure, "offset" is a keyword (not a variable) which means "get the offset of a member within a structure", and "union.asmdata" says which member of which structure to get the offset of.

It means you want to access the value of "union.asmdata", but for some reason is unable to use "union.asmdata" construct from C directly. Then may be it would be better if the code will look like:

Code: Select all

void fieldAccessFunction(GPR32 objectAddressReg, GPR32 fieldOffsetReg, GPR32 resultReg)
{
  mov resultReg, [objectAddressReg + fieldOfffsetReg]
}

?

embryo wrote:

Brendan wrote:but that's strange in assembly (where square brackets are used for the equivalent of pointer dereferencing) and would mean the assembler has to know the types of all registers (which would be complicated and likely to fail in non-trivial cases) just to figure out what type of structure it is.

As I understand your language is able to mix C-like code with Assembler-like one. Why not to use the same algorithm for type determination in case of assembly part, that is already used for C part of a program?

myGlobal as u32 = 1234

asmfunction myFunction(first as u32 in edx), second as u32) (void) {
    mov eax,first      ;An error (assembler doesn't know which register "first" is in)
    mov eax,edx        ;Correct way to get the value of "first"
    mov eax,second     ;Correct way to get the value of "second" ("second" is on the stack and not in a register)
    mov eax,myGlobal   ;Correct way to get the value of "myGlobal" ("myGlobal" is not in a register)
}

embryo wrote:

Brendan wrote:I do have a concept called "data properties" though. For example, if you've got a variable "foo" then "foo.max" gets the maximum value the variable can hold, "foo.size" gets the amount of bytes the variable consumes, etc.

It's a nice idea. But it is important to describe the area where the idea will be applicable. To my opinion the area is just a connection between high level code and the hardware level. And such connection, if exposed to the high level code, will compromise the "high" part of the level definition. Then such properties should be exposed in the connection level only. And a whole connection level should be rarely used by a developer to allow the high level view to be the most important for developer. In jEmbryoS I just wrap low level structure details within high level classes even when assembly is used, so it lets me to concentrate on the high level code.

embryo wrote:

Brendan wrote:What I'm considering doing is adding an "offset" property, so that people can do "myStructure.myMember.offset" to get the offset of myMember in the structure. In that case the original instruction would become "mov eax,[edi+union.asmdata.offset]" or (using the structure type's name directly instead of the function's input parameter name) "mov eax,[edi+myTaggedUnion.asmdata.offset]"

But even if it was decided to use such access method - why not to use compiler's ability to determine variable's type? Then it will be possible to write function like this:

Code: Select all

mov(eax, myTaggedUnion.asmdata);
// mov definition
void mov(GPR32 resultReg, int sourceValueAddress)
{
...
}

Brendan wrote:So what you're saying is that the reason you didn't provide an example to show that it's possible (while still making it look the same to other code) is that it's not possible to do this in Rust without breaking all the existing code that uses it.

Brendan wrote:I want assembly to be consistent with higher level language (if/where possible);

Brendan wrote:For assembly language the assembler can't/shouldn't keep track of what is in each register (it's virtually impossible to get right). For example:

Code: Select all

myGlobal as u32 = 1234

asmfunction myFunction(first as u32 in edx), second as u32) (void) {
    mov eax,first      ;An error (assembler doesn't know which register "first" is in)
    mov eax,edx        ;Correct way to get the value of "first"
    mov eax,second     ;Correct way to get the value of "second" ("second" is on the stack and not in a register)
    mov eax,myGlobal   ;Correct way to get the value of "myGlobal" ("myGlobal" is not in a register)
}

Brendan wrote:Creating a function to execute an instruction in assembly would be like extending the "Integer" class in Java just to create a "return first + second" method to add 2 integers.

Rusky wrote:

Brendan wrote:So what you're saying is that the reason you didn't provide an example to show that it's possible (while still making it look the same to other code) is that it's not possible to do this in Rust without breaking all the existing code that uses it.

How on earth does that follow from what I said? There will probably be no existing code using it because you can't have race conditions. When moving from single-threaded to multi-threaded, however, there's no reason you couldn't use accessor functions, just like in your example, to keep usage the same. The difference would be that the language would force you to do it correctly (when using built-in locks/etc), or force you to do it according to your specification (when implementing your own synchronization primitives) which is hopefully correct. Your language has no such guarantees.

embryo wrote:

Brendan wrote:I want assembly to be consistent with higher level language (if/where possible);

And your way of being consistent is with high level language constructs. Then here is the question - how tightly the assembly language should be integrated with the high level? Where is the limit?

embryo wrote:

embryo wrote:

Brendan wrote:For assembly language the assembler can't/shouldn't keep track of what is in each register (it's virtually impossible to get right). For example:

Code: Select all

myGlobal as u32 = 1234

asmfunction myFunction(first as u32 in edx), second as u32) (void) {
    mov eax,first      ;An error (assembler doesn't know which register "first" is in)
    mov eax,edx        ;Correct way to get the value of "first"
    mov eax,second     ;Correct way to get the value of "second" ("second" is on the stack and not in a register)
    mov eax,myGlobal   ;Correct way to get the value of "myGlobal" ("myGlobal" is not in a register)
}

It's not about tracking register content, but it's about an interface between high and low levels. When you write mov eax,second it's ok, but why not to write mov eax,someStructure.second? It's about the 'offset' keyword.

Brendan wrote:Hi,

Rusky wrote:

Brendan wrote:So what you're saying is that the reason you didn't provide an example to show that it's possible (while still making it look the same to other code) is that it's not possible to do this in Rust without breaking all the existing code that uses it.

How on earth does that follow from what I said? There will probably be no existing code using it because you can't have race conditions. When moving from single-threaded to multi-threaded, however, there's no reason you couldn't use accessor functions, just like in your example, to keep usage the same. The difference would be that the language would force you to do it correctly (when using built-in locks/etc), or force you to do it according to your specification (when implementing your own synchronization primitives) which is hopefully correct. Your language has no such guarantees.

I obviously don't know as much about Rust as someone that cares. I assumed that (like most languages designed to be usable for low-level work) it couldn't know if the code being compiled was single-threaded, or used something external (e.g. kernel API) for threading, or implemented it's own threading (e.g. an OS kernel), or if it did something more strange (like AP CPU startup code).

Of course I was wrong. Yesterday I found out it can know if there's concurrency or not because it rams a half-baked "user-space m:n threading" thing down everyone's throat, and that it can't even be used as free-standing in the first place.

Owen wrote:

Brendan wrote:I obviously don't know as much about Rust as someone that cares. I assumed that (like most languages designed to be usable for low-level work) it couldn't know if the code being compiled was single-threaded, or used something external (e.g. kernel API) for threading, or implemented it's own threading (e.g. an OS kernel), or if it did something more strange (like AP CPU startup code).

Of course I was wrong. Yesterday I found out it can know if there's concurrency or not because it rams a half-baked "user-space m:n threading" thing down everyone's throat, and that it can't even be used as free-standing in the first place.

Critical research failure. There are Rust kernels already. It rams no form of threading down your throat (though there are two threading option in the standard library)

Owen wrote:Rust doesn't care if your code is single or multi threaded.

Owen wrote:For most cases, you should just pass objects between threads (Rust statically guarantees that the old thread isn't holding onto a reference to the object). If you need shared state, then you use something like the RW<T> type, which uses unsafe blocks to implement a mutex-protected reference-counted pointer. The implementation of this uses Rust's lifetimes to ensure that you don't hold onto a reference to the contained object for longer than you hold onto the lock.

Owen wrote:I'll take pointers which protect me from lots of errors most of the time over unsafe pointers which protect me from none any day of the week.

Brendan wrote:For a simple example; let's say I want to implement an IRQ handler that does "tick++" and almost nothing else (an EOI and an IRET might be nice). Now, let's try to decipher the techno-babble...

Brendan wrote:The beautiful thing about C is that it's quite low level. It's easy to look at code written in C and imagine the assembly you expect and "know" what effect the code has on the CPU, memory, etc. Without this relatively strong connection between the source code and the underlying hardware, it's far too easy for programmers to ignore what their code actually does (e.g. which cache lines are touched, how expensive a function is, how much RAM is used where and why, etc). It's not something I want to destroy - it's one of the most necessary parts of the language. I want to force programmers to see their code in terms of micro-ops, loads and stores (not in terms of abstract black boxes).

Rusky wrote:It is a goal of the Rust creators that Rust code be able to run freestanding (a goal which is currently met). The language is still in development- why do you expect the first search result to automatically override the claims of people who actually use the language?

Rusky wrote:Why does a "memory model centered around concurrently-executing tasks" mean the compiler has to know if your code is single or multi-threaded and not just that the memory model takes into account the possibility of concurrent code?

Rusky wrote:Why do you bother to research and argue about Rust if you don't care about it?

Rusky wrote:

Brendan wrote:The beautiful thing about C is that it's quite low level. It's easy to look at code written in C and imagine the assembly you expect and "know" what effect the code has on the CPU, memory, etc. Without this relatively strong connection between the source code and the underlying hardware, it's far too easy for programmers to ignore what their code actually does (e.g. which cache lines are touched, how expensive a function is, how much RAM is used where and why, etc). It's not something I want to destroy - it's one of the most necessary parts of the language. I want to force programmers to see their code in terms of micro-ops, loads and stores (not in terms of abstract black boxes).

How does this have anything to do with (let alone preclude) static analysis of pointers?

Brendan wrote:the only major differences between assembly and higher level code is that assembly uses instructions with operands instead of statements and expressions, and the compiler won't do some of the safety checks it does for higher level code.

Brendan wrote:For "asmfunction foo(someStructure as myStructureType in edx) (void)" you told the assembler to put "someStructure" in the EDX register, so "mov eax,someStructure.second" is not fine (because the assembler doesn't track the contents of registers).

Rusky wrote:The "obfuscated cluster-bork of puke needed to attempt to make pointers safe" doesn't have any more "abstract black boxes" than C:

Rust pointers are just as transparent as C pointers, with some added compile-time restrictions. They have the concept of "ownership," where only one variable can own the pointed-to memory at a time. Other variables (usually arguments) can "borrow" a reference as well, and the compiler will verify that these references do not outlive the owner, which frees the memory at the end of its lifetime- when it goes out of scope, or gets something else assigned to it, etc.

• Macros
• Being forced to explicitly mark various things as safe or unsafe
• Being forced to explicitly mark pointers as owned or borrowed (or managed?)
• Their "traits"
• Their "implementations"
• Their "attributes" (including lint check attributes)
• Macros
• Conditional compilation
• Lamba expressions
• Generic functions
• Vector types
• Recursive types
• Closure types
• Their built in inter-task communication, scheduler, and everything that depends on their run-time

embryo wrote:

Brendan wrote:the only major differences between assembly and higher level code is that assembly uses instructions with operands instead of statements and expressions, and the compiler won't do some of the safety checks it does for higher level code.

But what about mixing of the instructions with expressions? The mov is an instruction, but one of it's operands can be an expression. The offset keyword is an example of such expression. And now the limit of the expression penetration into the assembly is important.

embryo wrote:

Brendan wrote:For "asmfunction foo(someStructure as myStructureType in edx) (void)" you told the assembler to put "someStructure" in the EDX register, so "mov eax,someStructure.second" is not fine (because the assembler doesn't track the contents of registers).

So we have an issue of a connection from high level structure to it's hardware placement (in memory or in registers). There should be some simple rules of applying such connection. If you use "in edx" clause then the rule requires from the compiler to place the someStructure address in edx, but it is the high level part of the new language and the clause constrains the compiler in it's ability to optimize high level code. May be it is better not to constrain the compiler and just remove "in edx"?