xenos1984 has quit [Read error: Connection reset by peer]
<klange>
Kernel needs some fixups, want to move the ramdisk loading to boot shim so the kernel doesn't need to care and the qemu one can keep doing fw-cfg while the rpi one will just have it embedded
<clever>
the rpi firmware can also load a ramdisk, and place it into the DT at the standard location
<mrvn>
klange: you can attach the ramdisk to the kernel
<klange>
I like the ramdisk being as separate as possible, I'll look into the firmware-provided option
<klange>
going to go ramdiskless to start, though, just to make sure I can get things working before I start running init, weed out all the assumptions from qemu
<clever>
`initramfs initramf.gz 0x00800000` or `initramfs initrd.img-3.18.7+ followkernel` in config.txt
<clever>
and it will either place the initrd at the specified addr, or after the kernel
<klange>
can it do more than one?
<clever>
i believe it can only accept one, you have to concat them yourself
<clever>
like `cat a b c > many` and then `initramfs many followkernel`
<mrvn>
clever: don't you forget the padding?
<clever>
yeah, your a/b/c files would need any padding required to reconstruct it
<klange>
provide your own padding ;) or avoid needing it
<clever>
yep
<clever>
the pi4 also has a firmware ramdisk
<clever>
if you set boot_ramdisk=1 in config.txt, then it will load boot.img from the fat32 partition
<clever>
and all other files (config.txt, start4.elf, kernel.img, your own initrd) are coming from boot.img (which is another fat32 fs)
<klange>
I don't like making fats, already enough pain from efi there :)
<Griwes>
hmmmmm just realized that I haven't actually implemented preemption yet, when trying to spin up a kernel thread to read what the initial userspace process sends as its logs
<Griwes>
implementing exactly what is necessary for the next step has its ups but it also has its surprises, like this one
<klange>
I discovered during my initial aarch64 bringup that my system could do a surprising lot of stuff without any tick
<klange>
until idle ran, most things would block on ipc enough to get to a semi-working gui
<clever>
the pi4 also has a 2d hw composition unit, so you could have pop-up windows running from their own bitmap images in ram
<Griwes>
I mean the only reason I have timers right now is because booting APs is slightly saner when you don't spin and try to divine if enough time has passed
<klange>
clever: I really do want to try to get a hardware backend for my compositor
<klange>
especially on an rpi where I already know my pure-C alphablit stuff is slow
<Griwes>
but I'm now trying to handle things that come in over a non-blocking syscall and, well, now I need preemption
<Griwes>
(I guess I don't technically need it because I could forcefully schedule to another core, but then booting with a single core would hang... ;p)
<mrvn>
if it's doing a syscall why don't you wake up the other thread?
<klange>
Speaking of SMP, I think I'm running a new enough firmware that my other cores should be blocked on a firmware spinlock waiting for an address, so my PSCI bringup should be easily adaptable.
<klange>
But first, a bit of work-work. I'll probably copy over some framebuffer text blitting into this stub loader during lunch, and get the MMU init running.
<klange>
Then I'll poke around at the previously discussed options for getting the actual kernel loaded.
<Griwes>
I am considering changing the naming of my syscall handlers already, because now I have a kernel thread that calls those interfaces directly, and having a direct call to "syscall_*_handler" looks a bit weird
<klange>
most of mine are lightweight wrappers that do userspace interfacy things and then call a regular kernel function... except the poll-related ones, those need cleanups
<Griwes>
well, I'm talking about that layer that is called by the userspace interfacy things
<Griwes>
though maybe I ought to have normal functions that support putting a thread to sleep on read too, without going through the ones dedicated for the syscalls
<Griwes>
s/read/read from a mailbox/
<klange>
i still need to implement some real synchronization apis :) misaka inherited toaru32's terrible 'wakeup queues' and only barely got a 'real' mutex API that thus far has only been used by some block storage drivers
xenos1984 has joined #osdev
<heat>
i got my system call tables in json and I have a python script that generates syscall stubs and a syscall.h header with all the syscall numbers
<heat>
initially I needed to scan every kernel file for a sys_* using libclang
<heat>
it was a fun little project
<heat>
geist, in the plic is a context a hart?
<geist>
yes
<geist>
there's a plic doc on the riscv github though it's pretty simple
<geist>
but it mentions a little bit of verbiage about what the terms are
<heat>
yeah I'm reading it but I was unsure of the meaning of "Hart context"
<heat>
hmm why does the plic have #address-cells = 0
<heat>
there's very clearly an address there
<mrvn>
heat: no child address, only parent?
<klange>
[dog with ball in mouth] no address, only size
<heat>
mrvn, wdym?
<mrvn>
heat: A range could only have one address I think
<clever>
ah, extended looks like a "better" version of interrupts
<heat>
ok this is horribly depressing
<heat>
interrupts-extended in riscv's case contains <phandle to cpu's interrupt-controller>, cause of trap
<heat>
where cause of trap is only 11 (machine external interrupts) and 9 (supervisor external interrupts)
<heat>
it doesn't tell me shit
<heat>
oh, do you think the local interrupt controller's interrupts-extended might have something useful?
<heat>
no, it just tells you it generates machine IPIs and machine timer interrupts
<heat>
something you could've figured out if you read the fucking spec
<geist>
well, sure
<geist>
sounds like they're just followig the rules
<heat>
sorry arm stans, acpi is better
<heat>
this settles it
<geist>
id say yes *except* the needing to run byte code
<geist>
that's a deal breaker for me
<geist>
though i suppose it'd be an intersting exercise to write a bytecode interpreter, so i'd at least know what the scope of it is
<klange>
dtb is just "hardcode everything" but fancier
<geist>
may be simpler than i think
<heat>
I think it's hard enough that everyone uses ACPICA
<heat>
except windows
<gog>
i will reimplement ACPI
<gog>
:D
<gog>
(no i won't)
<klange>
i will simply stop caring about my x86-64 port, consider it sufficiently done, and focus on rpi400 solely :P
<clever>
i think the official firmware de-init's the bcm2711 pci-e controller before running kernel.img, so you will need to refer to the linux source to know how to bring the pci-e back online
<heat>
wha
<clever>
the vl805 on the pi4 series also needs you to send a mailbox command to initialize its firmware, after the pci-e bar's are assigned
<gog>
i actually might begin to attempt to integrate acpica into my code
<gog>
but keep it in its own yucky little module
<gog>
i still have some infrastructure to put in to make that feasible
<geist>
yah and apica is fairly simple to port. my main complaint is it's huge. last i checked it compiles to something like 300KB text
<gog>
gross
<gog>
i'll kee it in its own yucky big module then
<heat>
170KB here
diamondbond has joined #osdev
<klange>
"newer firmwares allow the loading of multiple files by comma-separating their names." neat
heat has quit [Read error: Connection reset by peer]
<clever>
i had full 2d animations before i had text
<klange>
well I'm hoping to dump a bunch of debug output, and I didn't want to fiddle with a flakey uart after the horrible experience I've had with the ttl adapter I picked up
<clever>
my ftdi seems to randomly reconnect at the usb layer, sometimes just because a nearby fridge turned on/off
<klange>
and I have this little tiny terminal emulator (it even speaks a bit of dec/ansi) :P
<clever>
i got another 8086 branded uart adapter that fits directly onto the gpio header, it deadlocks if you send malformed uart data, until you closed and reopen the tty
<clever>
the only bug-free uart ive had so far, is connecting one pi directly to another pi
k8yun has joined #osdev
<clever>
abusing a pico might work, but ive not tried it yet
<nanovad>
I have some random FT232R based board that has worked great for the times I've used it as aux UART on Arduino stuff
<bslsk05>
www.pishop.ca: USB Console Stub - Serial adaptor for Raspberry Pi - PiShop.ca
sonny has quit [Remote host closed the connection]
diamondbond has quit [Ping timeout: 240 seconds]
dude12312414 has joined #osdev
Jari-- has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<Jari-->
morning all /s /w /p
<Jari-->
hi friends
[_] is now known as [itchyjunk]
<Jari-->
checked out the MS-DOS multitasking apparatus DR-DOS etc. .. it basically divided the CPU equally to all MS-DOS tasks, it multitasked, but it also made the applications equally slow
<Jari-->
so guys, what basically I am aiming to do is a CP/M compatible system, 32-bit / 64-bit and etcs.
<Jari-->
MP/M actually, because it is multitasking
<Jari-->
some guys could write me a MS-DOS wrapper for VM86 etc. virtualization
gog has quit [Ping timeout: 260 seconds]
zaquest has quit [Remote host closed the connection]
smeso has quit [Quit: smeso]
zaquest has joined #osdev
smeso has joined #osdev
<klys>
jari--, have a look at vm86plus, it's in linux
<bslsk05>
github.com: linux/vm86_32.c at master · torvalds/linux · GitHub
<klys>
jari--, I've noticed mainly about cpm, mpm, ccpm, that there is some difficulty in copying the files to your disk. do you have a way to do this?
<klys>
jari--, I have a few dos related bookmarks up at http://show.ing.me/ in case you want to browse more
<bslsk05>
redirect -> 45.55.20.239: show.ing.me: now seeing...
[itchyjunk] has quit [Read error: Connection reset by peer]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
rustyy has quit [Client Quit]
rustyy has joined #osdev
k8yun has quit [Quit: Leaving]
k8yun has joined #osdev
sonny has joined #osdev
<sonny>
Why bother with an OS if you can develop applications on UEFI?
<Mutabah>
In that case, the UEFI runtime is the OS
<sonny>
interesting
<sonny>
is anyone doing this yet? like running server programs on uefi?
<sonny>
I guess it doesn't do much in terms of seperation
<Mutabah>
Unlikely, the firmware interface is pretty limited - and likely the implementation is unoptimised
<sonny>
hmm
<CompanionCube>
iirc UEFI is also single-threaded
<sonny>
oh :/
<sonny>
is it a big spec? how would you describe it?
<CompanionCube>
modernised DOS in firmware?
matrice64 has joined #osdev
<sonny>
ah
k8yun has quit [Quit: Leaving]
<CompanionCube>
it's definitely modern, and there's enough MS influence to make it a DOS even if the command.com equiv isn't used much.
<sonny>
so, how did they get the big operating systems to agree on it? like why use it?
<Mutabah>
*shudder* guids and ucs-2 everywhere
<klys>
it seems clever developed efivim, an editor
<CompanionCube>
sonny: because intel and ms collaborated on it?
<sonny>
yeah but I'm trying to understand, it makes it easier to provide firmware for hardware vendors?
<klys>
I have a new allwinner d1 nezha dev board, and it came with a microsf card with 8 gpt partitions and uboot/opensbi
<klys>
s/microsf/microsd/
<CompanionCube>
or was it just intel
<CompanionCube>
hm
<Mutabah>
There is lots of MS in that spec
<Mutabah>
nobody else nowadays would make those decisions
<CompanionCube>
Mutabah: yes but was it put there by intel or MS themselves@
<klys>
the "bios" or "firmware" now has to be standardized so tightly it's provided by a standards body, and these days the standards bodies include acpica.org and tianocore.
<sonny>
I see, so if you want to develop an OS for say amd64 and such, you have to start here?
<CompanionCube>
sonny: it meets the very low bar of not being the classical bios
<klys>
major kernels such as linux link acpica's tarball into the kernel itself
<CompanionCube>
(and also was originally for itanium, not x86)
<sonny>
when I read about classical bios they don't go into much detail
<bslsk05>
j-core/jcore-soc - J-Core SoC Base Platfrom. Top level for FPGA platforms, pulls in CPU, BootROM and various IP blocks. (6 forks/16 stargazers/NOASSERTION)
<klys>
naw I haven't see it yet
<sonny>
seems similar in spirit, except this one is kinda fancy
<klys>
it runs jave bytecode?
<klys>
java*
<sonny>
no, I don't know why the name is j-core
<sonny>
"J-core is a clean-room open source processor and SOC design using the SuperH instruction set, implemented in VHDL"
<geist>
wow, superh
<geist>
that is... strange. maybe the 'j' stands for japan?
<geist>
where superh is i think still somewhat prevalent?
<sonny>
it caught my eye cause superh has a harvard architecture
<klys>
a soc is a modern type of cpu (with onboard peripherals), so an fpga dev board is for an ee project, and an soc dev board is for running and creating programming.
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<geist>
well, superh is nothing special, it was just hitachi's thing back in the 90s
<geist>
lots of arches are harvard in that they have separate I and D ports, but then you jsut make them point at the same back
<geist>
bank
<kazinsal>
looks like jcore was unveiled at LinuxCon Japan so yeah maybe that's the etymology
<sonny>
oh
<geist>
yah hitachi spun it off into Renesas and AFAICT it hasn't developed much since SH5
<geist>
but i occasionally see it floating around, but almost exclusively in japanese things
<sonny>
I don't like microops but it is interesting to me
<geist>
cameras, etc
<kazinsal>
and SH5 didn't seem to get any physical release
<geist>
yah
<geist>
and of course Dreamcast, which is where i fiddled with it first. ported my first OS to it from x86
<sonny>
oh woah
<geist>
it's about as different from x86 as you can get
<sonny>
x86 is crazy
<sonny>
imagine segments ... lol
<geist>
why imagine? they are there!
<sonny>
tried to do some DOS programming and boy was I confused
<sonny>
well, that's over now :D
<geist>
anyway, a little surprised doing a clean room superh is not fraught with some amount of legal heat
<geist>
aaah on wikipedia: As of 2015, many of the original patents for the SuperH architecture are expiring and the SH-2 CPU has been reimplemented as open source hardware under the name J2.
<sonny>
it's cool that clean rooms still happen
<sonny>
openocd seems to be everwhere, what on earth did people do before?
<geist>
for jtag? they do what they do without openocd: use tools that are not openocd
<sonny>
oh
<sonny>
prorbably proprietary
<geist>
they might have to pay for them though
<geist>
right
<sonny>
I think these toolchains could be organized better, I just can't accept the complexity ...
<sonny>
anyways, nice to have all these options
<sonny>
why choose j-core for a project with all this risc-v stuff?
<geist>
because it was done like 8 years ago
<klys>
riscv is a fledgeling arch with a clean implementation yet some difficulty expressing itself
<sonny>
ohhh
<geist>
and also why not
<sonny>
seemed easier to design risc-v products but if nothings available then yeah
<klys>
openpower is also available for free now
<sonny>
is that related to power9?
<klys>
yes
<sonny>
ok, so openpower is the overall class of processors or something?
<geist>
also sparc
<klys>
geist how free is sparc now? what licensing?
<geist>
i think it's pretty free
<geist>
i jsut know there are some pretty free cores out there and some used in things like space exploration and whatnot
<geist>
it seems that riscv has just sucked the air out of that particular room
<klys>
> In recent years the project has not been actively worked on, so users are strongly advised to use Princeton University's OpenPiton project instead: http://parallel.princeton.edu/openpiton/
<bslsk05>
parallel.princeton.edu <no title>
<klys>
> With OpenPiton Release 10, the new OpenPiton+Ariane brings the 64-bit Ariane RISC-V core to OpenPiton!
<klys>
it's still OpenSPARC in the intro to the documentation
sprock has quit [Ping timeout: 252 seconds]
<vdamewood>
Food?
<vdamewood>
Oops, rong channel.
<vdamewood>
wrong*
<geist>
noms are good
<vdamewood>
I'm thinking various chopped up vegetables with vinegar and oil on top.
<kazinsal>
I had a bacon cheeseburger. om nom nom
rustyy has quit [Ping timeout: 272 seconds]
rustyy has joined #osdev
<klys>
yea happy valentine's. for supper I went to a formal activity. was p.sweet.
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
<geist>
huh surprising. virtualbox doesn't seem to really like to use MSI-X
<geist>
and doesn't assign MSI for even things like e1000
<geist>
yah with all of the virtio stuff it understands, and e1000 and ahci, it only seems to give MSI to AHCI
<kazinsal>
yeah, they stubbed out the e1000 MSI stuff
<kazinsal>
oracle kinda doesn't give a shit
<geist>
well, at least they seem to give MSI-x to nvme
<geist>
of course oracle not giving a shit is not surprising
<geist>
i'm honestly surprised the whole thing wasn't just shit canned years ago
<CompanionCube>
how virtualbox has avoided the sidam touch i'll never know
<kazinsal>
it's been in maintenance mode for years unfortunately
<kazinsal>
it's just useful enough to keep fixing bugs in
<geist>
yah i eventually actually ended up paying for vmware for windows, but the cross platformness of virtualbox is still very enticing
<kazinsal>
when windows 10 was still in technical preview it took moooonths before they patched it to work properly
<kazinsal>
and had to do multiple patches as things changed in the technical preview because they were just doing something atrocious with calling windows' secure libraries or something
<kazinsal>
VMs would mysteriously fail to start with an incomprehensible error because they were basically doing the equivalent of raw syscalls
<geist>
yah there was a period maybe 3 or 4 years ago where virtualbox was broken on linux too
<geist>
which was when is stopped running it as my VM solution on my server, piddled with ESXi for a few years, and then switched back to just QEMU
<CompanionCube>
full replacement of vbox is libvirt no?
<geist>
i dont think there's a full replcaement for vbox in certain axis
<geist>
most notably it being portable to mac/windows/linux
<geist>
OTOH the mac stuff is quickly falling away as newer macs are ARM and i seriously doubt vbox will even attempt that
xenos1984 has quit [Remote host closed the connection]
<kazinsal>
yeah, I feel like vbox's core still gets updates because it's used in their cloud virtualization offerings
<kazinsal>
which exist primarily to SaaS-ize their database software
<kazinsal>
(because they wanted to charge even MORE money for it...)
xenos1984 has joined #osdev
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
m5zs7k has quit [Read error: Connection reset by peer]
m5zs7k_ has joined #osdev
m5zs7k_ is now known as m5zs7k
GeDaMo has joined #osdev
eroux has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
ElectronApps has quit [Remote host closed the connection]
dormito has joined #osdev
CaCode has joined #osdev
ElectronApps has joined #osdev
<klange>
I am getting to userspace, ld.so is loading init, I'm getting all the way through several syscalls, but fork() fails on return in the child process with an unknown exception... fun times
[itchyjunk] has joined #osdev
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 252 seconds]
diamondbond has joined #osdev
dennis95 has joined #osdev
CaCode has left #osdev [Leaving]
<klange>
i'm calling it a night; seems all I'm doing at this point is fighting over caching, so I'm on the cusp of a working system...
<klange>
maybe I need to adjust some control register things; rpi is dropping me off in el2 and I'm not sure I dropped down to el1 entirely correctly for what I expect out of the mmu
* klange
yawns loudly and steps away from the keyboard
diamondbond has quit [Ping timeout: 272 seconds]
lkurusa has joined #osdev
diamondbond has joined #osdev
gog has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
diamondbond has quit [Ping timeout: 272 seconds]
heat has joined #osdev
nyah has joined #osdev
sonny has joined #osdev
sonny has left #osdev [#osdev]
<zid`>
The problem with my capacity for error is that it's purely theoretical
<gog>
do i need any special initialization semantics for an atomic type? ATOMIC_VAR_INIT() is deprecated apparently and it seems to generate the right code when i do an increment
<heat>
no
<gog>
cool
<g1n>
hello
<g1n>
what would you recommend to implement next after page frame allocator (didn't have time to ask yesterday)
<g1n>
i am not sure yet when i am going to start implementing it, but would be cool to know for future :)
<gog>
a malloc()-type interface is a good thing to have for small objects
<mjg>
g1n: have you read the slab paper by bonwick
<g1n>
mjg: no
<mjg>
the key concept behind it is how everyone is doing memory allocation today
<g1n>
gog: so i am ready for that? i found this page - https://wiki.osdev.org/Writing_a_memory_manager , i think will be helpful. Also, i am not making anything virtual yet (i mean i am not really using paging for page frame allocator)
<bslsk05>
wiki.osdev.org: Writing a memory manager - OSDev Wiki
<gog>
idk maybe
<g1n>
gog: ok thanks, i will try
<g1n>
i think i need to jump to my other GRU projects, i hope for not very long time
<zid`>
next step imo is mmap that can't take NULL for left side
<zid`>
so just map arbitrary virtual address into memory, and pulls physical pages to do it off your stack
<mrvn>
g1n: After your page frame allocator you should change it to use a struct phys_add_t or struct page_frame_t for added safety. And then start on a virtual address space allocator and a MMU module to map/unmap memory.
<gog>
ok i'm getting an intermittent #GP weird
matrice64 has joined #osdev
<gog>
it works sometimes, other times it faults trying to write an io port
<mrvn>
I would ignore malloc and slabs and such for now. You don't need to allocate small objects for quite a while yet. You can do threads, interrupts, preemption, syscalls and basic user space tasks before you need it.
<gog>
i wonder if my host system is fucky
matrice64 has quit [Client Quit]
<mrvn>
g1n: One other really really important thing: setting up the exception handlers so they print some diagnostics.
<zid`>
"Your host system is funky" is a pretty good insult
<mrvn>
gog: are you maybe writing the wrong size?
<mrvn>
gog: or forgot volatile so the compiler optiomizes it out?
<gog>
it's a byte write, it's volatile, and it's happening without recompiliations
<gog>
i ran it 10 times in a row and it #GP'd twice
<zid`>
You'll have to take it out back and shoot it
<zid`>
nothing else to do
<gog>
probably
<zid`>
what are you writing to?
<j`ey>
gog: try a different emulator
<mrvn>
pretty sure it's not the outb. You can write to any port and the cpu won't care unless you've setup the IO bitmap to protect ports.
<gog>
zid`: 8259 pic
<zid`>
ah yea that's super weird
<zid`>
like.. *really* super weird
<gog>
i think it's the host
<mrvn>
gog: are you maybe getting an interrupt and that GPs?
<zid`>
ooh
<zid`>
yea, what if your write is enabling interrupts
<zid`>
and it immediately faults if one is pending
<gog>
that _could_ be it
<zid`>
which is.. sometimes a thing because of key repeat from grub or something
<gog>
maybe i should clear the irr
<mrvn>
you have to reset the PIC
<gog>
yeah
<gog>
i can see how there'd be a race happening there
<zid`>
I actually had that 'issue' on my pic impl at first, grub would keep an interrupt pending from the keyboard when I selected my OS sometimes
<zid`>
so I had to hit the key real fast :p
<gog>
yknow what i'm gonna tap some keys while it starts and see if it does it
<zid`>
I was just too lazy to not write a crashy handler until I'd done writing the code I was writing
<gog>
i can't seem to trigger it again
<gog>
¯\_(ツ)_/¯
<mrvn>
Are you getting a tripple fault?
<mrvn>
Heisenbug, don't look at it or it gets scared.
<gog>
no, my gp handler is installed at this point and it just stops dead
<gog>
but i haven't been able to trigger it again
<mrvn>
so what's the address that faults?
<zid`>
sounds fixed to me
<gog>
the address that faults is inside pic8259_init()
<gog>
and it's an inb not an outb
<zid`>
inb in a pic code?
<mrvn>
strange
<gog>
it's in the delay thing
<gog>
just read from 0x80 and discard
<gog>
although idek if that's actually necessary, i just did what the tutorial does
<zid`>
I just write 17 17 32 40 4 2 1 1 0 0 3 and it works in qemu at least :p
<mrvn>
what if you do "*(volatile int *)(0x12345678) = 23;"? Does it show the right PC and fault address?
<gog>
ehh i'm not gonna waste anymore energy trying to dig this up rn
<mrvn>
gog: just trying to test your GP handler.
<gog>
oh ok hold on
<gog>
well, what you're proposing won't GP, it'll PF, PF and DF
<mrvn>
right, my bad. oehm, how do you GP in kernel?
<gog>
i guess i could write a bad segment descriptor and do that
<zid`>
I just look at -d int
<zid`>
it's easier than writing handlers :P
<mrvn>
zid`: cheater :)
<_eryjus>
my guess is zid` is lazy -- and laziness has its motivations!
<gog>
lol ok idk i can't make it happen
<gog>
giving up this diversion now
<gog>
i suspect there's a race happening in there somewhere
<gog>
but i cba, i'm hungry and need more caffeine
matrice64 has joined #osdev
<gog>
omg it happened again
<gog>
ok
<mrvn>
did you try qemu and bochs?
<gog>
no just qemu
<mrvn>
kvm?
<gog>
no kvm
<mrvn>
All 3 behave differently in subtle ways. Sometimes one can highlight a problem better than the other.
<gog>
offset 1dec, first byte of inb()
<gog>
old excetption is -1 on int trace
<gog>
so it's a straight #GP
<mrvn>
did you install a TSS?
<gog>
yes my tss is installed at this point
<mrvn>
and you didn't block any IO ports?
<gog>
nope, iopb is 0
<gog>
the instruction is a push rbp
<mrvn>
your inb() isn't static inline?
<gog>
it's not
<gog>
probably should be?
<gog>
or are you teasing me
<mrvn>
performance wise it's irelevant, inb/outb take forever. But code wise doing a function call for a single asm opcode is just wstefull.
<mrvn>
also prevents the compiler from picking the best register to use for the opcode.
<mrvn>
anyway, if the push fails then it's probably a bad stack pointer
<gog>
stack pointer and segment are correct
<gog>
stack is in an rw memory region, mapped in
<_eryjus>
gog, what do you do before your inb() call? anything that might clobber your GDT?
<gog>
i don't think it should
<mrvn>
_eryjus: a bad gdt would fault when loading segment registers I believe, not on push
<gog>
error code is 2, so write
<gog>
which yeah
<gog>
obv
<mrvn>
and your SP is correct and not underflowing?
<_eryjus>
mrvn: i was wondering if it was clobbered after the load. i believe that fact is hidden for some time without faulting -- which is probably what you are describing
<gog>
it's in identity-mapped memory and it has way more than enough space
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<_eryjus>
wait, can push throw anything other than #GP(0)?
<GeDaMo>
#GP(0) If the memory address is in a non-canonical form. #SS(0) If the stack address is in a non-canonical form. #PF(fault-code) If a page fault occurs. #AC(0) If alignment checking is enabled and an unaligned memory reference is made while the current privilege level is 3. #UD If the LOCK prefix is used. If the PUSH is of CS, SS, DS, or ES.
<bslsk05>
www.kernel.org: The Kernel Address Sanitizer (KASAN) — The Linux Kernel documentation
<Bitweasil>
There's probably a way to make it work, but I'd imagine it involves a good bit of custom plumbing.
<Bitweasil>
Because you're not "requesting memory from something else," you *are* that something else.
<zid`>
Basically, it's only going to work at a decently high level.
<zid`>
Otherwise you're just.. writing an allocator that supports auditing itself a little.
<j`ey>
Bitweasil: I think heat added kasan to his kernel
<gog>
ok i managed to stand up long enough for a shower
<mrvn>
loks like it just adds some canaries in shadow memory
xenos1984 has quit [Remote host closed the connection]
<mrvn>
should be easy to port to your own kernel
xenos1984 has joined #osdev
<heat>
yes I added kasan to my kernel
<heat>
there's a standard layout + docs for asan if you want to agressively inline asan checks and whatnot (clang does this by default for example), but if you turn that off you can use essentially anything you want
<heat>
as long as it tracks memory
<heat>
you just need to implement the kasan callbacks
<bslsk05>
github.com: Onyx/build_grub_efi_image.sh at master · heatd/Onyx · GitHub
<bauen1>
iirc klanges bootloader is somewhat mb (or mb2 ??) compatible, so it's not that dead, there's at least two implementations i know of :D
<zid`>
hmm, looking at mb2 spec, it's really similar
<zid`>
but apparently.. still 32bit?
<heat>
gives you a .efi you can use
<heat>
zid`, yes
<heat>
it's very different though
<heat>
completely different way of parsing things
<heat>
it can also give you a bunch more stuff
<zid`>
at least they rewrote it not to use negative indexing
<zid`>
I only use the e820 and module list (to get the kernel elf, which I may not need this way)
<heat>
it can pass you the EFI runtime table, it can give you the RSDP (which you need if you're on UEFI)
<heat>
also it can relocate the kernel in physical memory for you
<zid`>
never touched uefi, don't have the tooling for you
<zid`>
and I don't need it to relocate me I just need a stub that maps -2GB to phys_load_addr and enters long mode
<mrvn>
" The field ‘architecture’ specifies the Central Processing Unit Instruction Set Architecture. Since ‘magic’ isn’t a palindrome it already specifies the endianness ISAs differing only in endianness recieve the same ID. ‘0’ means 32-bit (protected) mode of i386. ‘4’ means 32-bit MIPS.
<mrvn>
" The official specs don't even list ARM or PPC.
<heat>
ok
<zid`>
so atm I just have a stub that'd be there either way given a 32bit entry point, but becuase of mb1 they're split into two files
<zid`>
rather than embedding one into the other
<heat>
you can have 32-bit code inside a 64-bit elf
<zid`>
yes
<zid`>
>rather than embedding one into the other
<mrvn>
zid`: that part is 100% identical with mb2. You just parse the boot infos differently and have a few new options for efi.
<zid`>
which is what this line signifies
<heat>
in mb2 since it can load ELF64s you don't need an objcopy, you don't need anything
<heat>
just make your cute little elf64
<heat>
and boot it
<mrvn>
heat: mb2 can't load ELF64, only grub can
<zid`>
what sorta page tables do I get?
<heat>
none
<mrvn>
zid`: none, it's still 32bit on entry. You still need the stub
<zid`>
So I get a 32bit entry?
<heat>
the boot state is the same as multiboot
<zid`>
yea so literally the only difference
<zid`>
is whether one is inside the other or not
<heat>
sí
<zid`>
so Cons: I have to rewrite it, I lose multiboot support
<zid`>
Pro: One small files ends up inside another
<heat>
you don't need a separate stage
vin has joined #osdev
<mrvn>
zid`: you don't have to include it. The benefit for you could be to have a EFI stub as alternative.
<zid`>
I could write an EFI stub regardless though?
<heat>
you get more portability (because you can't legally scan the RSDP in UEFI)
<mrvn>
zid`: efi + mb1 doesn't work.
<zid`>
what
<zid`>
why would I need *both*
<zid`>
I said I could write an *efi* stub
<heat>
well you can
<zid`>
not.. do silly hacks to boot my mb1 stub via efi.
<heat>
but the efi stub is also a silly hack
<mrvn>
zid`: oh, you mean a real efi PE stub. You don't have the tooling for that.
<zid`>
Yes, so I won't, but I could
<zid`>
mb2 won't change that point
<mrvn>
zid`: I meant you can write an mb2 stub that copes with EFI tags.
<heat>
ok so, why would you want mb2: it's like mb1 but portable
<mrvn>
zid`: efi -> grub-efi -> mb2
<heat>
and boots you in BIOS systems and EFI systems without a need to write a silly EFI stub
<mrvn>
zid`: no need for new tooling there
<zid`>
Okay that's an actual reason :D
<zid`>
so maybe if I ever go toward efi I will make mb2 handle the efi parts
<heat>
there are no explicit EFI parts for booting, really
<zid`>
someone still has to make a valid efi image
<zid`>
and it isn't going to be me
<heat>
no.
<mrvn>
zid`: grub-efi did that
<zid`>
so if grub wants to include one on their end in grub2 and chain load my crap, I'm willing to let them
<zid`>
mrvn: yes, welcome to the conversation
<zid`>
it was even your suggestion
<heat>
the only difference for efi in mb2 is that it can pass you the runtime table (so you can write variables and whatnot)
<zid`>
not sure you how you forgot
<heat>
but you don't really realistically need that unless you're installing a bootloader
<zid`>
yea I won't actually *touch* the efi crap
<zid`>
but if I ever want to be bootable from an efi env, I will just let grub2 do it
<zid`>
via, as mrvn loves repeating, efi-grub :p
<zid`>
grub-efi*
<heat>
okay no, there's a small adjustment: mb2 passes you the rsdp
<mrvn>
and you want to exit bootservices
<heat>
it saves you from scanning memory and it's the only way to get the rsdp in UEFI (it's not definied to be in any memory region)
<zid`>
that's completely fine
<zid`>
why are you suddenly trying to talk me *out* of grub2/
<mrvn>
all crap you handle in your stub
<zid`>
You were the one trying to talk me into it
<mrvn>
heat: have you tried booting a ELF64 with mb1 signature in grub?
<heat>
yes
<zid`>
adding a sometimes-null pointer to a copy of the rdsp to pass to acpi_init isn't much of a deal
<mrvn>
heat: who added ELF64 to the mb2 code without adding it to the mb1 code too? That's just stupid.
<zid`>
it's all stupid
<zid`>
nobody wants to take charge of dealing with page table prisons
<heat>
zid`, parse_rsdp(p ?: find_rsdp())
<heat>
ftfy :P
<zid`>
no thanks
<zid`>
I'd actually just re-assign the pointer irl
<zid`>
if(!p) p = find_rsdp(); parse_rsdp(p);
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
gog has joined #osdev
<geist>
right, and even after the if you can check that it's not still null
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<heat>
i've found that on OVMF you can even find bogus rsdp's if you search through memory
<gog>
ok so i've narrowed it down to _when_ it happens, and it happens after i tell PIC0 the ICW1, the IMR and IRR are cleared to 0, RFLAGS.IF is clear
<gog>
and then booop, cpu gets vectors to e=00
<zid`>
heat: bogus as in, the string rdsp, or bogus as in matching checksum?
<gog>
even with RFLAGS.IF clear
xenos1984 has quit [Remote host closed the connection]
<gog>
i have verified that they are clear before the command is sent to the pic
<zid`>
The former you'd sorta expect just from.. the code that filled out the rdsp maybe doing mov eax, rdsp so it appears in the .text of your bios somewhere or whatever
<heat>
zid`, can't remember. but it's totally undefined
xenos1984 has joined #osdev
<heat>
you're not actually going through fw .text when you search
<zid`>
If the checksum matches then that's just a boog
<heat>
gog, how do you get interrupt 0?
<zid`>
that's error code 0
<gog>
no, it's interrupt 0
<zid`>
oh did I misread
<gog>
or rather, it's either 00 OR f0 depending on when the CPU gets vectored
<gog>
if it's after the PIC is remapped it's f0
<_eryjus>
interrupt 0 not IRQ0
<heat>
no it's not
<heat>
it's error 0
<zid`>
kek
<heat>
the v= says the vector
<gog>
ok
<gog>
in the two times i was able to trigger it i got both
<heat>
wait you still get v=00?
<gog>
v=00
<gog>
and v=f0
<gog>
the first time was before the pic was remapped
<heat>
wtf
<gog>
the second time after
<heat>
wtf
<heat>
wtf
<gog>
yes
<heat>
this is cursed
<gog>
and RFLAGS.IF is clear
<gog>
this is because the timer is firing
<gog>
but why is the CPU getting vectored????
<heat>
conspiracy theory
<gog>
i have triple and quadruple checked RFLAGS
<gog>
and i can make this happen consistently if i step it with gdb
<gog>
but sometimes it happens before and sometimes after PIC irq_base is changed
heat_ has joined #osdev
<heat_>
cheers internet
<heat_>
<heat> you're not programming the PIC correctly, the PIC's base is 0 and the internal qemu/KVM code doesn't check for IF in interrupts within the exception range
<heat_>
this is my conspiracy theory
heat has quit [Ping timeout: 250 seconds]
<gog>
but how do i avoid it? when you send ICW1 the irq_base and imr get cleared
<gog>
and evn still, it happens after the irq_base is set sometimes
<gog>
and the interrupt output shows v=f0
<zid`>
I mean, these should all just set some 'pending' pins
<zid`>
which you are ignoring because cli
<zid`>
it shouldn't affect internal cpu sstate, it's emulating an external chip that has an interrupt line
<gog>
idek why i did irq_lock and irq_unlock there
<heat>
gog still checkmates gog
<zid>
this is why you shouldn't write code
<zid>
Just, in general.
<gog>
yeah
<mrvn>
gog: you should implement macros to do RAII
<zid>
Leave everything unimplemented then it can't be implemented badly.
<gog>
i'm a terrible programmer
<heat>
you know what would stop this?
<zid>
That's my trick, anyway
<heat>
rust
<heat>
rewrite it in rust
<zid>
I mean.. no it wouldn't? :P
<heat>
why would it not
<zid>
asm("sti"); in the wrong place is always going to enable interrupts
<zid>
not a lot you can do about that
<heat>
rust saves everything
<zid>
ah sorry my mistake
<mrvn>
zid: hard to do that accidentally
<heat>
rust made me fertile again
<zid>
Rust cured my baldness
<zid>
now my hair is filling my room and suffocating me, help
<mrvn>
zid: knot a rope and climb out of the window
<zid>
I'm not sure that's how topology works
<zid>
if you tie your own hair to yourself then jump out of a window
<zid>
you're going full eggshell
<mrvn>
who said jump? I said climb
<zid>
yea sitll not 100% sure you see the problem
<gog>
well i fixed it now
<gog>
thanks everybody for trying to help even though i insisited the problem wasn't my code :|
<zid>
I believed in you.
<zid>
(That you'd put an sti somewhere and forgot, I 100% believed this)
<gog>
in my defense i've been on some mildly powerful painkillers?
<j`ey>
*brainkillers
<zid>
yes that is worrying, why not proper full strength ones that let you see time
<heat>
you can write rust on those
<heat>
C? not so much
<zid>
rust kills pain anyway
<zid>
It makes you invulnerable to stabbing weapons too
<gog>
they wouldn't give me the good shit
<heat>
i believe that if you find a bug you should rewrite code in rust, and every code has a bug if you look hard enough
<zid>
The trick is to mention your rampant painkiller abuse as a teenager
<zid>
and how high your tolerance is
<gog>
lol
<zid>
see how rewarding not lying to your doctor is
<gog>
i'll never not lie again
<gog>
i mean, i'm always going to tell the truth from now on :)
<zid>
If I asked the other guard, how would he respond?
<gog>
he would t-- li----
<gog>
¯\_(ツ)_/¯
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
masoudd has quit [Ping timeout: 252 seconds]
mahmutov has quit [Ping timeout: 252 seconds]
sonny has joined #osdev
sonny has left #osdev [#osdev]
<clever>
geist: oh, random idea, related to superscalar processor talk from earlier, could the i-cache also be caching a pre-decoded form of opcodes, and tracking what opcodes are non-conflicting?
<mrvn>
clever: would that be worth it? Each bit is expensive in i-cache
<clever>
mrvn: was thinking more that instead of an icache slot holding a 32bit opcode, it would hold a pre-decoded result, so the pipeline can be 1 stage shorter
<clever>
the slots would just be a different size
<clever>
and yeah, that may wind up using more bits per 32bit addr
<mrvn>
How would that work with branch targets? The opcode could conflict with any of the opcodes before a jump to the target.
<clever>
anything + branch will basically not conflict, since the branch is just setting PC
<clever>
and whatever you jumped to, runs in another clock, and gets checked seperately, as another opcode pair
<clever>
and pc-relative stuff just has to use the right pc, from that anything+branch pair
<heat>
hmm
<heat>
why is tcg so much slower than rosetta?
<zid>
It has to open loads of card packs to get the opcodes it needs
<mrvn>
Say you have: op1; l: op2; op3; b l op1 and op2 don't conflict but op3 and op2 do. But you cached that op2 has no conflicts and just run it after the branch and BOOM
<clever>
mrvn: i was thinking, you could have a bool that kind of exists between addresses
<clever>
so it would be more like op1, bool1, op2, bool2, op3
<clever>
bool1 means op1/op2 dont conflict
<clever>
and bool2 means op2/op3 dont conflict
<clever>
so any time you get to an address, you can check the bool between addr and addr+1, and then run both opcodes at once
<mrvn>
op1; l: op2; op3; op4; op5; b l, op5 ... op3 might conflict while op1 op2 op3 does not.
<clever>
mrvn: i would consider `b l` to be another opcode, and it can only run `op5 + b l` in a given clock
<mrvn>
clever: you can't just look at the opcode before to determine conflicts.
<clever>
so op2/op3 doesnt come into play until after the branch
<clever>
i'm thinking conflicts in terms of running 2 opcodes in the same clock, not conflicts from running it back2back in 2 clocks
<mrvn>
clever: so you limit yourself to a CPU that can decode at most 2 opcodes?
<clever>
if its dual-issue, and can run 2 at once, and has no ooo
<mrvn>
clever: if you are limited to 2 and always in fixed pairs then that would work.
<mrvn>
clever: if you execute "b l + op2" then you have to ignore the cached bit.
<clever>
that starts to get into branch prediction, but if those are in the same cache line, i could see how you could pre-determine that the branch is to a fixed or predictable addr, and that `op2` doesnt conflict
<clever>
and store that in the cache line
<mrvn>
clever: if you don't have some complex "decrement reg + jump if > 0" opcode then I guess a branch can never conflict with anything.
<clever>
this is an opcode ive used on the VPU (and gcc uses it too), add, compare, branch not equal
<clever>
in this case, its basically `if (r10-- == 0) goto` but i may have the -- on the wrong side
<clever>
ah, and !=
<mrvn>
I think on early alphas the cpu would decode 2 opcodes at a time but always an aligned pair. Branching into the middle of a pair would waste the first slot.
dormito has joined #osdev
<clever>
that gives me an idea
<heat>
addcmpbne is absolutely spooky
<clever>
the VPU is dual-issue, and i have observed 2 opcodes running in the exact same time as 1 opcode could run in
<clever>
but, if i change the alignment, what happens?
<clever>
i'm guessing nothing in this case, since it accepts 16bit, 32bit, 48bit, and 80bit opcodes
<clever>
alignment is already whack
<mrvn>
m68k had a decrement and branch, an "if (i-- > 0) goto label"
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<zid>
but none of them are actually risc
<mrvn>
clever: That's my strongest indicator for being risc: the fixed opcode size.
<heat>
riscv has no fixed opcode size
simpl_e has joined #osdev
<j`ey>
cisc-v then
<mrvn>
heat: riscv is a lopad/store arch, right?
<heat>
yes
<nomagno>
heat: I just took a look at RV32I yesterday and I didn't really get that impression
<nomagno>
It has variable length instructions, but it's fairly easily decidable
<clever>
nomagno: thumb vs arm32 kind of has similar?
<zid>
risc is a dead term since the 80s
<nomagno>
No, my bad... It has 32-bit fixed size instructions? See I never understood this
<zid>
nothing has been risc, we're just on a very narrow window of 'extremely cisc' and 'almost entirely cisc' :p
<clever>
where opcodes can be either 16bit or 32bit, and bit0 of the addr (during a branch) signals what size your using
<mrvn>
clever: never used thumb on arm.
<clever>
mrvn: when mixing, the assembler will tag each function as thumb or arm, and the linker will then set bit0 of the addr to tell the cpu if your branching to thumb or arm code, you can then freely mix both in any 32bit arm binary
<nomagno>
How can you fit 32 bit address space in 32-bit fixed size instructions?
<clever>
gcc can be told to generate thumb or arm, -mthumb i think it was
<nomagno>
You can never refer to the entire address space
<kazinsal>
register indirects
<mrvn>
nomagno: by not having any 32bit immediates
<clever>
nomagno: arm solves that with ldr, where you load a 32bit constant from a pc-relative address
<clever>
and then you have a small table of 32bit constants after each function
<mrvn>
nomagno: you can't actually access memory by address, only by register.
<clever>
yeah, ldr just puts that 32bit constant into a register
<clever>
and then you load by addr in reg
<nomagno>
That sounds very cumbersome
<mrvn>
Or you load the high and low 16 bit values in 2 opcodes.
<clever>
nomagno: the assembler generates the constant table automatically
<mrvn>
nomagno: you hardly ever have a fixed address to access. You usualy access some pointer you have in a register with a small offset.
<nomagno>
I went for an extremely simple approach for my P-code CPU: 0 operand instruction -> 1 byte; 1 operand instruction -> 3 bytes; 2 operand instruction -> 5 bytes;
<clever>
nomagno: `ldr r8, =SLCR_BASE` for example, says that you want the addr of a symbol in r8, the assembler will generate a constant table later in the .o, and then generate a pc-relative load opcode
<mrvn>
nomagno: remember: RISC was designed so the compiler can generate fast code. Not for you to have nice ASM.
<nomagno>
mrvn: that's fair
<clever>
so the above turns into a pair of 32bit products, one in your .text, and one in your .ltorg (literal origin)
<mrvn>
nomagno: looking at it in C term you can't do *(int*)0x1234 = 23; You have to do: int *p = 0x1234; *p = 23; It's not really hard to write asm for ARM.
<mrvn>
99% of the time you need p a few times in a function and would make that variable anway.
xenos1984 has quit [*.net *.split]
heat has quit [*.net *.split]
rorx has quit [*.net *.split]
PapaFrog has quit [*.net *.split]
woky has quit [*.net *.split]
LambdaComplex has quit [*.net *.split]
kleinweby has quit [*.net *.split]
onering has quit [*.net *.split]
<clever>
and we lost the heat!
<clever>
i just fixed the furnace too! lol
xenos1984 has joined #osdev
rorx has joined #osdev
LambdaComplex has joined #osdev
PapaFrog has joined #osdev
woky has joined #osdev
kleinweby has joined #osdev
onering has joined #osdev
<clever>
weird, still isnt back, lol
<zid>
The highest order CISC cpu has exactly one instruction 'dwiw', pronounced 'do what I want'
<gog>
need that cpu
<klange>
I am going to put the RPi away until the weekend. I am growing aggravated over... presumably caching.
<clever>
klange: the 2d scan-out isnt coherent with the arm caches
<clever>
so you need to either write-combine or cache-flush for the framebuffer to become visible
[itchyjunk] has quit [Ping timeout: 272 seconds]
<clever>
and if your doing any kind of dma from hw->ram, you have to discard the arm caches for the area dma wrote to
<graphitemaster>
Should've put it away last weekend, that way this weekend you could've saved on time.
<graphitemaster>
Cached RPi
[itchyjunk] has joined #osdev
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<geist>
re: mixed 16 and 32 bit instructions. riscv does a good job with it. the bottom few bits of the opcode itself is the size of the instruction
<mrvn>
clever: isn't that normal for frame buffers?
<geist>
so it actually fairly nicely mixes the two,much better than thumb did
<zid>
how do you find them if they're at the bottom
<geist>
little endian
<zid>
I always neglect to consider that a cpu might store things as *words* in a VLE
<mrvn>
Can you do 16bit 32bit 16bit?
<geist>
yes
<zid>
being sane, and all
<moon-child>
VLE?
<moon-child>
variable length encoding?
<zid>
variable length enc
<clever>
mrvn: i thought that x86 dma was almost always coherent with the caches, but that framebuffer tends to be in gpu ram, so the card isnt actually using dma normally
<geist>
so for example you get pretty good usage of it:
<nomagno>
My CPU is... Uh, big-endian, 8-bit words, pure Harvard architecture, 16-bit address space, 16 instructions {halt, nop, set, jmp, jcz, jcnz, add, sub, cmp, and, or, xor, rot, func, ret, call}. Instructions are composed of: [literal/pointer mask (4 bits), opcode (4 bits), 0-2 operands (16 bits each)]. Each operand can be an address which is read from / written to, a literal (usually only the lower 8 bits go used in this case, but for jumping the full
<nomagno>
16 go used), or a pointer (Interpret the ((ADDRESS << 8) | (ADDRESS+1)) as an address). No registers or anything
<mrvn>
clever: well, x86 is quite the execption with coherence.
Mutabah has joined #osdev
<nomagno>
As you can see... It's quite non classifiable in terms of physical/real RISC/CISC distinction
<geist>
re: getting large values into registers on riscv, line 22 and 23 in that paste is a good example of that
<geist>
ie, auipc/addi pair
<zid>
nomagno: The classification I would use is "micro", where it doesn't apply
<mrvn>
nomagno: I would say that is clearly CISC
<mrvn>
nomagno: not load/store, not fixed opcode size, complex address modes
<geist>
from that descriptio, sounds like a lot of mainframes and minis in the 60s and 70s
<geist>
that particular pattern of word with opcode + register + immediate/address i've seen a lot
<geist>
ie, say PDP-10 or so
<geist>
though actually re-reading what you wrote that's variable sized instructions, which is different than what i just dedscribed
<nomagno>
It's fairly fun to toy around with specially because I provide a preprocessor script along with the VM implementation
<nomagno>
I guess it's fine for what it's meant to: User generated content engine