feat: add support of address-lookup-table program #94
Conversation
| // - [0]: Instruction discriminator (1 byte, u8) (2 for Extend) | ||
|
|
||
| // LOOKUP_TABLE_MAX_ADDRESSES == u8::MAX + 1. | ||
| let mut instruction_data = [0; 8196]; // TODO: huge for stack, maybe forget about no_std and use vector |
There was a problem hiding this comment.
@febo What do you think about such a huge array initialization?
Max addresses to extend is 256 x 32 + 4 for discriminator.
Otherwise I can use Vec<Pubkey>, as it's done in the original program, but we lose no_std for this.
Maybe you have other, better approaches to tackle it? Maybe use features and make 2 realizations for std and no_std ways?
There was a problem hiding this comment.
Vec is just a wrapper for the allocation. both alloc::boxed::Box or alloc::alloc::alloc would allocate on the heap.
There was a problem hiding this comment.
8196 won't fit on the stack, so it needs to be less than 4096 (a bit less than that since there are other things that will go on the stack). Perhaps it would be easier if we define a trait Addresses that represents the instruction data in this case. Then we can have no_std and std implementations for it.
We can use a alloc::vec::Vec for the std variant.
There was a problem hiding this comment.
Why is it important to support no_std?
I assume these programs are compiled in two variants:
- An SBF target, which supports
std, it just output an SBF bytecode. - Unit tests, that might be running in the host configuration. This should also support
std. But I can also see that a lot of the basic platform API will either panic or fail on a non-solanaplatform. So this use case might actually be limited.
There was a problem hiding this comment.
it requires you to use things that are "closer to the bare metal" which leads to the resource-wise solution and easier backward compatibility.
and this is easier for the performance optimizations when you have no work with a lot of overhead
| // - [0]: Instruction discriminator (1 byte, u8) (2 for Extend) | ||
|
|
||
| // LOOKUP_TABLE_MAX_ADDRESSES == u8::MAX + 1. | ||
| let mut instruction_data = [0; 8196]; // TODO: huge for stack, maybe forget about no_std and use vector |
There was a problem hiding this comment.
Vec is just a wrapper for the allocation. both alloc::boxed::Box or alloc::alloc::alloc would allocate on the heap.
sonicfromnewyoke
force-pushed
the
sonic/address-lookup-table
branch
from
e71d31e to
5cdb6d7
Compare
No description provided.