On Thu, 8 Nov 2018 21:56:16 +0100, Philipp Klaus Krause <pkk@spth.de> wrote:>Am 08.11.18 um 20:52 schrieb upsidedown@downunder.com: >>> >>> But static memory allocation would require one copy of each function per >>> thread. >> >> For a foreground/background monitor, the worst case would be two >> copies of static data, if both threads use the same rubroutine. >> >>> And the linker would have to analyze the call graph to always >>> call the correct function for each thread. >> >> Linker for such small target ? > >Of course. The support routines the compiler uses reside in some >library, the linker links them in if necessary. Also, the larger >variants are not that small, with up to 256 B of RAM and 8 KB of ROM. >One might want to e.g. have one .c file for handling I�", one for the >soft UART, etc.A linker is required, if the libraries are (for copyright reasons) delivered as binary object code only. However, if the library are delivered as source files and the compiler/assembler has even a rudimentary #include mechanism, just include those library files you need. With a include or macro processor with parameter passing, just invoke same include file or macro twice with different parameters for different static variable instances. Of course, linkers are also needed, if very primitive compilation machines are used, such as floppy based Intellecs or Exorcisers. It could take a day to compile a large program all the way from sources, with multiple floppy changes to get the final absolute file to a single floppy, ready to be burnt into EPROMS for an additional hour or two. In such environment compiling, linking and burning only the source file changed would speed up program development a lot. When using a modern PC for compilation, there are no such issues.
$0.03 microcontroller
Started by ●October 9, 2018
Reply by ●November 8, 20182018-11-08
Reply by ●November 9, 20182018-11-09
Am 08.11.18 um 23:35 schrieb upsidedown@downunder.com:>>>> And the linker would have to analyze the call graph to always >>>> call the correct function for each thread. >>> >>> Linker for such small target ? >> >> Of course. The support routines the compiler uses reside in some >> library, the linker links them in if necessary. Also, the larger >> variants are not that small, with up to 256 B of RAM and 8 KB of ROM. >> One might want to e.g. have one .c file for handling I²", one for the >> soft UART, etc. > > A linker is required, if the libraries are (for copyright reasons) > delivered as binary object code only. > > However, if the library are delivered as source files and the > compiler/assembler has even a rudimentary #include mechanism, just > include those library files you need. With a include or macro > processor with parameter passing, just invoke same include file or > macro twice with different parameters for different static variable > instances. > > Of course, linkers are also needed, if very primitive compilation > machines are used, such as floppy based Intellecs or Exorcisers. It > could take a day to compile a large program all the way from sources, > with multiple floppy changes to get the final absolute file to a > single floppy, ready to be burnt into EPROMS for an additional hour or > two. In such environment compiling, linking and burning only the > source file changed would speed up program development a lot. > > When using a modern PC for compilation, there are no such issues. >Separate compilation and then linking is the normal thing to, and a common workflow for small devices. This is e.g. how most people use SDCC, a mainstream free compiler targeting various 8-bit architectures. That doesn't mean it is the only way (and since SDCC does not have link-time optimization it might not be the optimal way either). But it is something people use and expect to work reasonably well. So for anyone designing an architecture it would be wise to not put too many obstacles into that workflow. Philipp
Reply by ●November 11, 20182018-11-11
Am 12.10.18 um 22:45 schrieb upsidedown@downunder.com:> On Fri, 12 Oct 2018 22:06:02 +0200, Philipp Klaus Krause <pkk@spth.de> > wrote: > >> Am 12.10.2018 um 20:30 schrieb upsidedown@downunder.com: >>> >>> The real issue would be the small RAM size. >> >> Devices with this architecture go up to 256 B of RAM (but they then cost >> a few cent more). >> >> Philipp > > Did you find the binary encoding of various instruction formats, i.e > how many bits allocated to the operation code and how many for the > address field ? > > My initial guess was that the instruction word is simple 8 bit opcode > + 8 bit address, but the bit and word address limits for the smaller > models would suggest that for some op-codes, the op-code field might > be wider than 8 bits and address fields narrower than 8 bits (e.g. bit > and word addressing). >It is more complicated. Apparently the encoding changed from a 16-bit instruction word used by older types (https://www.mikrocontroller.net/topic/461002#5616813) to a 14-bit instruction word used by newer types (https://www.mikrocontroller.net/topic/461002#5616603). Padauk also dropped and added various instructions at some points (e.g. ldtabh, ldtabl, mul, pushw, popw). Philipp
Reply by ●December 26, 20182018-12-26
