View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000660 | LDMud 3.6 | General | public | 2009-06-15 16:30 | 2022-10-06 21:38 |
| Reporter | zesstra | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | closed | Resolution | suspended | ||
| Target Version | 3.6.0 | ||||
| Summary | 0000660: Offsets during lambda compilation: simplify code generation and waste space? | ||||
| Description | compile_value() reserves for branches one byte for the offset in the bytecode during the first pass. It later performs a back-patching pass to write the correct offsets into the bytecode (which are unknown during the first pass). But if it happens that a byte is not big enough for the offset, it has to increase the size of the offsets for all previous branch points and move the bytecode backwards for each of the previous branch points. This does not happen often. AFAIK the vast majority of offsets are short ones. But on the other hand the additional byte does not cause much harm for us and it simplifies compile_value() and bytecode generation. Additionally, lambdas are anyway rare compared to other code and inline closures easier to read and write. ;-) So I am thinking about simplifying the code and make generated lambdas a bit less efficient concerning memory space. Concerning execution speed there may be no significant difference between reading a uint8 or uint16 on modern machines. | ||||
| Tags | No tags attached. | ||||
| child of | 0000661 | confirmed | Bytecode cleanup |
|
|
Setting to feedback since I would like to hear opinion from other people on this. ;-) |
|
|
I agree fully. Let's spend that additional byte. |
|
|
I think, that nowadays it is not needed anymore to save every possible byte of memory. If it cleans up code and code generation, I'd also simplify it by spending one more byte. |
|
|
We are closing for now. Not because we changed our minds, but the priority is rather low. Also Gnomi prefers to do some cleanup during normal work/changes and it may just get done without ticket. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-06-15 16:30 | zesstra | New Issue | |
| 2009-06-15 16:30 | zesstra | Status | new => assigned |
| 2009-06-15 16:30 | zesstra | Assigned To | => zesstra |
| 2009-06-15 16:33 | zesstra | Relationship added | child of 0000661 |
| 2009-06-15 16:33 | zesstra | Relationship added | parent of 0000606 |
| 2009-06-15 16:34 | zesstra | Relationship deleted | parent of 0000606 |
| 2011-01-11 08:19 | zesstra | Note Added: 0001950 | |
| 2011-01-11 08:19 | zesstra | Assigned To | zesstra => |
| 2011-01-11 08:19 | zesstra | Status | assigned => feedback |
| 2011-01-25 15:07 | Gnomi | Note Added: 0001957 | |
| 2011-02-24 00:20 | Coogan | Note Added: 0002032 | |
| 2015-04-29 18:59 | zesstra | Project | LDMud 3.5 => LDMud 3.6 |
| 2015-04-29 18:59 | zesstra | Category | LPC Compiler/Preprocessor => General |
| 2015-04-29 19:03 | zesstra | Target Version | 3.5.0 => 3.6.0 |
| 2022-10-06 21:38 | zesstra | Status | feedback => closed |
| 2022-10-06 21:38 | zesstra | Resolution | open => suspended |
| 2022-10-06 21:38 | zesstra | Note Added: 0002706 |
