Was surprised to see this only discussed in reference as a use for static linking ability; thought there was already a formal request (if I've somehow missed it, apologies, but I searched issues/discussions here and /twinbasic).
I propose tB should support native syntax for inline assembly. tB eliminates some use cases for this, but could never anticipate all of them.
The most appropriate option, I think, it to allow it within functions; whole modules could be covered by static linking. There would be a traditional declaration, followed by function that may also contain tB code, that allows syntax to begin and end a block of assembly.
There's a number of good options for syntax; I propose the best way is to have a line starting with a character that would otherwise be illegal as a first, to avoid conflicts with existing names.
Public Function ThisHasASM() As Long
Call SomethingElse
@ASM
assembly here
@End ASM
End Function
The end syntax matches traditional block end syntax, and if there's still plans to change attribute syntax to @? If attributes inside methods would be too difficult, well the leading character isn't too important so long as it's not valid as a first character for any other use.
While it's certainly 'not BASIC' being an actual different language, I'd again point to the current state of usage: For the rare cases where no suitable alternatives exist, we already have the situation of VBx using assembly through several methods, so this is not introducing something to the language entirely without precedent and current examples. The trick has an inline asm addin for VB6, but more commonly, it's seen as a bunch of inscrutable magic hex values written to an executable location or called with DispCallFunc/CallWindowProc. So there's no avoiding the fact that it will be used in tB just like it's used in VBx-- in fact I tested a project using asm thunks in tB just the other day, it worked fine.
So it's not a question of whether this can be kept out, it's a question of should it be made friendlier and more accessible, thus increasing tB's power and ease of use for advanced programming? I see no reason why not. Especially given that it's sufficiently difficult only the most skilled and experienced programmers would use it, making it unlikely we'd see a bunch of junk asm code mucking things up for beginners, because it's rare and not even approachable until you have the sense to understand when it should be used.
Was surprised to see this only discussed in reference as a use for static linking ability; thought there was already a formal request (if I've somehow missed it, apologies, but I searched issues/discussions here and /twinbasic).
I propose tB should support native syntax for inline assembly. tB eliminates some use cases for this, but could never anticipate all of them.
The most appropriate option, I think, it to allow it within functions; whole modules could be covered by static linking. There would be a traditional declaration, followed by function that may also contain tB code, that allows syntax to begin and end a block of assembly.
There's a number of good options for syntax; I propose the best way is to have a line starting with a character that would otherwise be illegal as a first, to avoid conflicts with existing names.
The end syntax matches traditional block end syntax, and if there's still plans to change attribute syntax to @? If attributes inside methods would be too difficult, well the leading character isn't too important so long as it's not valid as a first character for any other use.
While it's certainly 'not BASIC' being an actual different language, I'd again point to the current state of usage: For the rare cases where no suitable alternatives exist, we already have the situation of VBx using assembly through several methods, so this is not introducing something to the language entirely without precedent and current examples. The trick has an inline asm addin for VB6, but more commonly, it's seen as a bunch of inscrutable magic hex values written to an executable location or called with DispCallFunc/CallWindowProc. So there's no avoiding the fact that it will be used in tB just like it's used in VBx-- in fact I tested a project using asm thunks in tB just the other day, it worked fine.
So it's not a question of whether this can be kept out, it's a question of should it be made friendlier and more accessible, thus increasing tB's power and ease of use for advanced programming? I see no reason why not. Especially given that it's sufficiently difficult only the most skilled and experienced programmers would use it, making it unlikely we'd see a bunch of junk asm code mucking things up for beginners, because it's rare and not even approachable until you have the sense to understand when it should be used.