Hmmm. Write Z80 first, then port to 6502? Write 6502 first, then port to Z80? Write 68000 first, then port to both Z80 and 6502? Write a bytecode interpreter on both 6502 and Z80 and then code to that bytecode?
I guess I'm looking for an excuse to think about writing code instead of, you know, actually writing code.
@jbqueru in the 70s I had an Ohio Scientific C3 computer which had a 6502, Z80 and, well, just the 6800. Code could hot switch between processors in about 100ms. Initially I wrote code for the Z80 but the OS CP/M ran on the 6502 and it had to switch way too much. So I ported CP/M to the Z80 and things ran much better.
I added disk caching to the OS b/c the floppies clacking was too annoying. Ran sweet.
All this about 2 yrs before Gates sold IBM on MSDOS and had to get rights to CP/M.
@bscloutier oh, that's interesting stuff. I haven't worked much with asymmetric multiprocessing, and the little that I did ran the processors in parallel (Megadrive, NeoGeo, Falcon030) so I never had to worry about the cost of switching.
@bscloutier Yeah, those older CPUs don't like to share with other bus masters. The Z80 is somewhat more amenable to it (e.g. the Amstrad CPC graphics component steals cycles from the Z80), the 6502 likes that a good deal less (e.g. the 6502 derivative in the NES does weird things during audio DMA cycles).
@mariani1 my challenge now is not to fall for that seduction and to finish my current project instead. If I keep changing focus 2 months into 6-month projects, I'll never get anything out.
@patrick I'm routinely torn by such discussions, because I'm too obsessed about performance.
On the one hand, I like the idea of high-level languages exposing capabilities that are otherwise unnatural at the assembly level because of limited CPU capabilities.
On the other hand, I am horrified by the overhead that those high-level constructs imply.
What might act as a tie-breaker could be the possibility of squeezing an interpreter into time-constrained routines, such as on the Atari 2600.
@jbqueru Create a set of "powerful ASM macros" or i.e. a sort of "pseudo asm" and code with that OR "use a C compiler" for all of them OR "write you own language/compiler" ( FORTH maybe ? ) OR just write the code STOP looking for excuses ! 😎
@gilesgoat But looking for excuses is so much more satisfying! I can blame other people for their mistakes (which I'm sure made perfect sense at the time) without making any mistake of my own!
@jbqueru I think that's more or less how I ended up retargetting a C compiler to a CPU with no 8-bit byte addressing, a segmented memory model, and maybe some other unusual choices I have not discovered yet...
@jbqueru it's Sunplus/GeneralPlus unSP, used in the VTech V.Smile and a few other consoles from early/mid 2000s. It seems somewhat similar to the C16x family, and also somewqat to the PDP11, but it has only 8 registers(of which 4 really usable by the code after you remove sp, pc, ...)
I hope I can soon write C code and ignore most of the details of the cpu :)
@pulkomandy@jbqueru The only Surplus/Generalplus chips I've poked at were the 6502 derivatives.
I thought it hilarious that their cheapest ones were a 6502 subset, as if shaving a few transistors off the CPU core was going to materially reduce the chip cost. Clearly it was just product differentiation. Some manage must have said, "Let's drop one of the index registers", so engineers did. But it's even more hilarious that the one they dropped was Y, generally the more useful of the two.
@brouhaha@pulkomandy Technically, I'm not sure you can drop X, because you then lose TXS / TSX... (yes, you could implement replacement instructions with A or Y, but that wouldn't be compatible with 6502 any more).
@jbqueru It's not what you expect given those names, though. The 68000 fundamentally has one level of interpretation. The nanocode is partially decoded ROM the provides part of the microinstruction but the same nanocode row is used in multiple microcode rows. There's only one microinstruction sequencer that addresses both ROMs. It's really just a form of ROM compression.
@brouhaha Oh, that makes sense, essentially a level of indirection for the common instruction components (addressing modes come to mind) if I understand correctly.
@jbqueru Yes. It's common sequences like controlling a memory write cycle, or setting the condition codes. But it's not really subroutines. They are inline, and act simultaneously with microcode. The "microcode ROM" supplies part of the micro instruction, and the "nanocode ROM" (actually a PLA) supplies a different part, so every microinstruction is made up of both.
@brouhaha I love your explanation. That's what I had in mind, and you help make my understanding sharper. That explains well how a MOVE can have advanced isntruction modes for both source and destination, or instructions like LEA and PEA.
@jbqueru It's quite entertaining to me to not-quite-randomly encounter someone else interested in some of the same computer microarchitecture minutiae as I am.
:-)
@brouhaha I like those details, because they can help me understand patterns in the way those systems work, instead of having to memorize long lists of facts without understanding them.
@jbqueru I feel as if I had similar things in my mind.... in the 1980s.
sigh Pretty sure I don't have access to any of that code. From the day I took my first programming class, until the day I got my first computer, was 12 years, and I was programming, on other people's systems, even before that first class. ;(
So many things I contributed to lost to time, and others' systems.
@teajaygrey You were well ahead of me. Up until (I think) 1990, I had only worked with variants of BASIC. I did have some documentation for Z80 assembly, buy didn't grok it (and didn't have the tools). I picked up 68000 assembly in 1990, I saw some i386 and some PPC in the 90s, a bit of ARM after that, but I've only really picked up 8-bit CPUs recently.
@jbqueru ah yeah, I was incarnated as a human this lifetime in Menlo Park and was surrounded by others' systems that most only might know from history books.
Even today, my parents' old church in Menlo Park shares a parking lot with SRI (Stanford Research Institute) and I knew other folks at SRI like Doug Engelbart and Bill English personally.
Lamentably, I didn't begin formal instruction in programming until maybe 1981 or so? In New Mexico. Candidly, it felt as if I had gone backwards in time, technologically, by decades. ;( It was an excruciatingly frustrating experience for me, I remember crying on occasion because I couldn't yet touch type and the piece of shit mainframe that class used had a timeout on login set to 60 seconds on their green and black terminals or something clearly not designed with a six year old who had already been using GUIs for years in mind.
Not the last time such an experience would occur either. For some reason I ended up going to a college in Minnesota in the 1990s. That campus had a 56K uplink, for their entire school! I had a 14.4 modem personally and I was a poor kid, not some USR HST warez courier like some of my friends in highschool. But, already in highschool I was repeatedly being invited to tweak code (and some microcode) for the SGIs and Sun Microsystems at nps.navy.mil. Two sysadmins at the Naval Postgraduate School, even asked me to be co-SysOps on BBSes they ran for fun outside of work.
I don't even remember my first programming language anymore, but I remember taking a class in Logo in the 1980s which inspired me to learn z80/x86 and 6502 asm, because Logo was so friggin slow! I asked around how video games were rendering things so quickly and learned about going lower level and "Racing the Beam". By the time I finally got to real C compilers they seemed bloated to me. The first graphics library I used in college, felt like cheating.
I still <3 asm but find I rarely get to enjoy it like I used to these days. ;(
I can relate to the learning process of going from a high-level language down to the metal, and then bring horrified at the cost of the abstractions built on top of that.
Add comment