Is pop with length similarly feasible in hardware?
It would be more convenient than requesting hardware vector lengths and setting up backwards indexing
pop v r length vecptr
len := max hardwareveclen length
v := vecptr[0 .. len - 1]
r := vecptr + len
Search found 15 matches
- 2024-09-14, 23:54:23
- Forum: forwardcom forum
- Topic: Fushed push with bounds check
- Replies: 5
- Views: 11618
- 2024-09-06, 13:49:37
- Forum: forwardcom forum
- Topic: Self-synchronizing ISA
- Replies: 5
- Views: 2625
Re: Self-synchronizing ISA
Interesting idea The refutation is unconvincing: "It would be using more of the precious code bits": Maybe, but there would be the same amount of single-word instructions since that takes 2 bits either way. "Large immediates": The leading bit can be switched by instruction varian...
- 2024-05-06, 12:21:34
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
Once again.. once again you are ignoring the most important points and I have to repeat myself: Most important of all, you said "WILL SUPPORT" dllopen, ergo dynamic linking will be an option, it will be used and must be designed and optimized. Fragmentation is inevitable. Flat sequences of...
- 2024-05-05, 11:24:27
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
It's frustratingly difficult to find any serious research comparing the two. In the meantime, you're still not acknowledging that static linking huge graphical libraries is unacceptable, this is an obvious case where the functions and transitive dependencies are large and massively shared across man...
- 2024-05-04, 17:13:44
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
Alright, I see the need to take the static vs dynamic linking debate from the top. In the first place, this is still frequently debated, to give my conclusion upfront, I'm not in favor of imposing a decision one way or another. My opinion here is the compiler should maintain a database of functions ...
- 2024-05-04, 12:34:01
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
"only a very small fraction of (DLLs) them are actually used". This is remedied by splitting them. The aspect of this project I appreciate the most is its uncompromising nature: For the most part I can really believe in the longevity of the solutions presented. And then.. here it is insist...
- 2024-05-03, 19:34:31
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
"A module is what comes from an object file. A library can contain multiple modules, each containing a function." This definition isn't very rigorous and still unclear. I wasn't talking about static linking, which is rather standard but not exactly a good solution, known to bloat programs ...
- 2024-05-03, 11:01:17
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
'Module' doesn't match much in the manual The idea to relink each function and all their transitive dependencies dynamically is potentially very expensive, especially as compared to the almost free copying in of libraries; Granted this wastes some memory but I take that over complicated CPU intensiv...
- 2024-05-02, 21:35:35
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
It appears that partially copying library functions quickly becomes difficult as soon as any of them depend on each other. As a quick example; `f = .. ; g = f ; h = f;` If you want to use only 'h', due to relative offsets you are probably forced to copy g since selectively copying and relinking only...
- 2024-04-15, 18:51:05
- Forum: forwardcom forum
- Topic: Fushed push with bounds check
- Replies: 5
- Views: 11618
Re: Fushed push with bounds check
Nice
It would also allow pushing vector registers without needing to carry around their size separately
It would also allow pushing vector registers without needing to carry around their size separately
- 2024-02-16, 13:55:11
- Forum: forwardcom forum
- Topic: Fushed push with bounds check
- Replies: 5
- Views: 11618
Fushed push with bounds check
I don't know if it makes sense at the hardware level, but the common dynamic array push operation wants to do a bounds check either immediately before or after the write.
- 2024-01-30, 16:05:31
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
"Multi-entrypoint functions are possible in assembly code, but cannot be coded in high level language" This is obviously dependent on the high level language. In any event languages are more likely to want to do this automatically. Partially compatible libraries with multiple versions of t...
- 2024-01-30, 15:35:03
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
Let's re-examine the question from the top: Suppose I am an object that requires 'malloc'. The Elf solution to this is for the object to list all libraries that may contain the imported symbols (DT_NEEDED), then have relocations either to PLT or to text with eager binding and relocate-readonly enabl...
- 2024-01-30, 14:46:04
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Re: Proposal for symbol lookup in the linker
[redundant text removed] I'm not disputing that copying only the parts of a library used into memory can sometimes improve the caching and theoretically with the kernel's help even bypass the mmap tables (This really needs to be measured though as sharing also sounds optimal in many cases), but even...
- 2024-01-28, 19:00:46
- Forum: forwardcom forum
- Topic: Proposal for symbol lookup in the linker
- Replies: 23
- Views: 66246
Proposal for symbol lookup in the linker
Resolving names can take an unacceptable amount of time, and are one of the reasons linking happens lazily on linux, leading to read+executable PLT sections etc.. Mangled names can be huge and the standard technique will always do at least one full strcmp. It seems desirable to eagerly bind all symb...